The Hacker Chronicles - A…the Computer Underground/The Hacker Chronicles - A Tour of the Computer Underground (P-80 Systems).iso/network/nia74

Text File | 1992-09-26 | 153KB | 3,259 lines

   Founded By:    |  _                        _______
 Guardian Of Time |  __      N.I.A.   _      ___   ___  Are you on any WAN? are
   Judge Dredd    |  ____     ___    ___    ___     ___ you on Bitnet, Internet
------------------+  _____    ___    ___    ___     ___  Compuserve, MCI Mail,
  \           /      ___ ___  ___    ___    ___________  Sprintmail, Applelink,
   +---------+       ___  ___ ___    ___    ___________    Easynet, MilNet,
   | 05MON18 |       ___   ______    ___    ___     ___    FidoNet, et al.?
   | File 74 |       ___    _____    ___    ___     ___ If so please drop us a
   +---------+               ____     _     __      ___        line at
                              ___           _       ___  [e-mail]
     Internal Affairs BBS      __   NIA074
                                _    Network Information Access
                                       Ignorance, There's No Excuse.

                            NIA Issue 074 Volume 2


     "I didn't invent the Unix security problem.  I just optimized it."


        Greetings.  This newsletter is published on a non-regular basis and
is only a hobby by the editors, not a job.  No responsibility is taken by
the editors for this newsletter, all of that and the credit goes to the
contributers.  We are changing format again to go with the changing times.
First of all, there will be NO news unless it is first hand accounts of it.
If you want news, there are plenty of other electronic 'zines and more
efficient ways of getting it than to wait for an NIA issue to come out.
Second, the articles are going to be getting technical.  There is only
so many intro/basics we can publish/re-print.
        We are looking for contributions.  All articles submitted must be in a
regular format for the magazine.  There is a one month review time for the
article to be chosen.  There is an additional one month revise time if the
article is chosen.  We do keep copies of everything that is sent to us so if
it is not published in the immediate issue than it could be published in a
later issue (in which case you will be notified).  The readers make the
magazine, so if you want to see better issues then do some research and
send us reports.

------------------------------------------------------------------------------
1. Introduction ......................................................Editors
2. Security Problems in TCP/IP Suite [01/02] ...................S.M. Bellovin
3. Security Problems in TCP/IP Suite [02/02] ...................S.M. Bellovin
4. Firewalls: The Design of Secure Internet Gateway ............Bill Cheswick
5. Notes on Centigram Systems ......................................Anonymous
6. How to Steal Information .......................................The Butler
7. Killer Chips: Physical Virus ...................Jean-Bernard Condat [CCCF]
------------------------------------------------------------------------------

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                             NIA074 / File 02

              Security Problems in the TCP/IP Protocol Suite

                              Part I of II

                              S.M. Bellovin

                          AT&T Bell Laboratories

                                 ABSTRACT

                 The TCP/IP protocol suite, which is very
                 widely used today, was developed under
                 the sponsorship of the Department of
                 Defense.  Despite that, there are a
                 number of serious security flaws
                 inherent in the protocols, regardless of
                 the correctness of any implementations.
                 We describe a variety of attacks based
                 on these flaws, including sequence
                 number spoofing, routing attacks, source
                 address spoofing, and authentication
                 attacks.  We also present defenses
                 against these attacks, and conclude with
                 a discussion of broad-spectrum defenses
                 such as encryption.

       1.  INTRODUCTION

       The TCP/IP protocol suite[1][2], which is very widely used
       today, was developed under the sponsorship of the Department
       of Defense.  Despite that, there are a number of serious
       security flaws inherent in the protocols.  Some of these
       flaws exist because hosts rely on IP source address for
       authentication; the Berkeley "r-utilities"[3] are a
       notable example.  Others exist because network control
       mechanisms, and in particular routing protocols, have
       minimal or non-existent authentication.

       When describing such attacks, our basic assumption is that
       the attacker has more or less complete control over some
       machine connected to the Internet.  This may be due to flaws
       in that machine's own protection mechanisms, or it may be

       __________

         * Author's address: Room 3C-536B AT&T Bell Laboratories,
           600 Mountain Avenue, Murray Hill, New Jersey 07974.

       Reprinted from Computer Communication Review Vol. 19
       No. 2, p.32-48, April 1989.

       because that machine is a microcomputer, and inherently
       unprotected.  Indeed, the attacker may even be a rogue
       system administrator.

       1.1  Exclusions

       We are not concerned with flaws in particular
       implementations of the protocols, such as those used by the
       Internet "worm"[4][5][6].  Rather, we discuss generic
       problems with the protocols themselves.  As will be seen,
       careful implementation techniques can alleviate or prevent
       some of these problems.  Some of the protocols we discuss
       are derived from Berkeley's version of the UNIXr system;
       others are generic Internet protocols.

       We are also not concerned with classic network attacks, such
       as physical eavesdropping, or altered or injected messages.
       We discuss such problems only in so far as they are
       facilitated or possible because of protocol problems.

       For the most part, there is no discussion here of vendor-
       specific protocols.  We do discuss some problems with
       Berkeley's protocols, since these have become de facto
       standards for many vendors, and not just for UNIX systems.


       2.  TCP SEQUENCE NUMBER PREDICTION

       One of the more fascinating security holes was first
       described by Morris[7].  Briefly, he used TCP sequence
       number prediction to construct a TCP packet sequence without
       ever receiving any responses from the server.  This allowed
       him to spoof a trusted host on a local network.

       The normal TCP connection establishment sequence involves a
       3-way handshake.  The client selects and transmits an
       initial sequence number ISNC, the server acknowledges it and
       sends its own sequence number ISNS, and the client
       acknowledges that.  Following those three messages, data
       transmission may take place.  The exchange may be shown
       schematically as follows:

            C->S:SYN(ISNC)
            S->C:SYN(ISNS),ACK(ISNC)
            C->S:ACK(ISNS)
            C->S:data
                 and/or
            S->C:data

       That is, for a conversation to take place, C must first hear
       ISNS, a more or less random number.

       Suppose, though, that there was a way for an intruder X to
       predict ISNS.  In that case, it could send the following
       sequence to impersonate trusted host T:

            X->S:SYN(ISNX),SRC=T
            S->T:SYN(ISNS),ACK(ISNX)
            X->S:ACK(ISNS),SRC=T
            X->S:ACK(ISNS),SRC=T,nasty-data

       Even though the message S->T does not go to X, X was able to
       know its contents, and hence could send data.  If X were to
       perform this attack on a connection that allows command
       execution (i.e., the Berkeley rsh server), malicious
       commands could be executed.

       How, then, to predict the random ISN?  In Berkeley systems,
       the initial sequence number variable is incremented by a
       constant amount once per second, and by half that amount
       each time a connection is initiated.  Thus, if one initiates
       a legitimate connection and observes the ISNS used, one can
       calculate, with a high degree of confidence, ISNS' used on
       the next connection attempt.

       Morris points out that the reply message

            S->T:SYN(ISNS),ACK(ISNX)

       does not in fact vanish down a black hole; rather, the real
       host T will receive it and attempt to reset the connection.
       This is not a serious obstacle.  Morris found that by
       impersonating a server port on T, and by flooding that port
       with apparent connection requests, he could generate queue
       overflows that would make it likely that the S->T message
       would be lost.  Alternatively, one could wait until T was
       down for routine maintenance or a reboot.

       A variant on this TCP sequence number attack, not described
       by Morris, exploits the netstat[8] service.  In this attack,
       the intruder impersonates a host that is down.  If netstat
       is available on the target host, it may supply the necessary
       sequence number information on another port; this eliminates
       all need to guess1.
        __________

        1. The netstat protocol is obsolete, but is still present
           on some Internet hosts.  Security concerns were not

       Defenses
       Obviously, the key to this attack is the relatively coarse
       rate of change of the initial sequence number variable on
       Berkeley systems.  The TCP specification requires that this
       variable be incremented approximately 250,000 times per
       second; Berkeley is using a much slower rate.  However, the
       critical factor is the granularity, not the average rate.
       The change from an increment of 128 per second in 4.2BSD to
       125,000 per second in 4.3BSD is meaningless, even though the
       latter is within a factor of two of the specified rate.

       Let us consider whether a counter that operated at a true
       250,000 hz rate would help.  For simplicity's sake, we will
       ignore the problem of other connections occurring, and only
       consider the fixed rate of change of this counter.

       To learn a current sequence number, one must send a SYN
       packet, and receive a response, as follows:

                   X->S: SYN(ISNX)
                   S->X: SYN(ISNS),ACK(ISNX)                           (1)

       The first spoof packet, which triggers generation of the
       next sequence number, can immediately follow the server's
       response to the probe packet:

                   X->S: SYN(ISNX),SRC=T                               (2)

       The sequence number ISNS used in the response

            S->T: SYN(ISNS),ACK(ISNX)

       is uniquely determined by the time between the origination
       of message (0) and the receipt at the server of message (0).
       But this number is precisely the round-trip time between X
       and S.  Thus, if the spoofer can accurately measure (and
       predict) that time, even a 4-second clock will not defeat
       this attack.

       How accurately can the trip time be measured?  If we assume
       that stability is good, we can probably bound it within 10
       milliseconds or so.  Clearly, the Internet does not exhibit
       such stability over the long-term[9], but it is often good
       enough over the short term.2 There is thus an uncertainty of
        ____________________________________________________________

           behind its elimination.

       2500 in the possible value for ISNS.  If each trial takes 5
       seconds, to allow time to re-measure the round-trip time, an
       intruder would have a reasonable likelihood of succeeding in
       7500 seconds, and a near-certainty within a day.  More
       predictable (i.e., higher quality) networks, or more
       accurate measurements, would improve the odds even further
       in the intruder's favor.  Clearly, simply following the
       letter of the TCP specification is not good enough.

       We have thus far tacitly assumed that no processing takes
       places on the target host.  In fact, some processing does
       take place when a new request comes in; the amount of
       variability in this processing is critical.  On a 6 MIPS
       machine, one tick -- 4 M-seconds -- is about 25
       instructions.  There is thus considerable sensitivity to the
       exact instruction path followed.  High-priority interrupts,
       or a slightly different TCB allocation sequence, will have a
       comparatively large effect on the actual value of the next
       sequence number.  This randomizing effect is of considerable
       advantage to the target.  It should be noted, though, that
       faster machines are more vulnerable to this attack, since
       the variability of the instruction path will take less real
       time, and hence affect the increment less.  And of course,
       CPU speeds are increasing rapidly.

       This suggests another solution to sequence number attacks:
       randomizing the increment.  Care must be taken to use
       sufficient bits; if, say, only the low-order 8 bits were
       picked randomly, and the granularity of the increment was
       coarse, the intruder's work factor is only multiplied by
       256.  A combination of a fine-granularity increment and a
       small random number generator, or just a 32-bit generator,
       is better.  Note, though, that many pseudo-random number
       generators are easily invertible[10].  In fact, given that
       most such generators work via feedback of their output, the
       enemy could simply compute the next "random" number to be
       picked.  Some hybrid techniques have promise -- using a 32-
       bit generator, for example, but only emitting 16 bits of it
       -- but brute-force attacks could succeed at determining the
       seed.  One would need at least 16 bits of random data in
        ____________________________________________________________

        2. At the moment, the Internet may not have such stability
           even over the short-term, especially on long-haul
           connections.  It is not comforting to know that the
           security of a network relies on its low quality of
           service.


       each increment, and perhaps more, to defeat probes from the
       network, but that might leave too few bits to guard against
       a search for the seed.  More research or simulations are
       needed to determine the proper parameters.

       Rather than go to such lengths, it is simpler to use a
       cryptographic algorithm (or device) for ISNS generation.
       The Data Encryption Standard[11] (DES) in electronic
       codebook mode[12] is an attractive choice as the ISNS
       source, with a simple counter as input.  Alternatively, DES
       could be used in output feedback mode without an additional
       counter.  Either way, great care must be taken to select the
       key used.  The time-of-day at boot time is not adequate;
       sufficiently good information about reboot times is often
       available to an intruder, thereby permitting a brute-force
       attack.  If, however, the reboot time is encrypted with a
       per-host secret key, the generator cannot be cracked with
       any reasonable effort.

       Performance of the initial sequence number generator is not
       a problem.  New sequence numbers are needed only once per
       connection, and even a software implementation of DES will
       suffice. Encryption times of 2.3 milliseconds on a 1 MIPS
       processor have been reported[13].

       An additional defense involves good logging and alerting
       mechanisms.  Measurements of the round-trip time --
       essential for attacking RFC-compliant hosts -- would most
       likely be carried out using ICMP Ping messages; a
       "transponder" function could log excessive ping requests.
       Other, perhaps more applicable, timing measurement
       techniques would involve attempted TCP connections; these
       connections are conspicuously short-lived, and may not even
       complete SYN processing.  Similarly, spoofing an active host
       will eventually generate unusual types of RST packets; these
       should not occur often, and should be logged.

       3.  THE JOY OF ROUTING

       Abuse of the routing mechanisms and protocols is probably
       the simplest protocol-based attack available.  There are a
       variety of ways to do this, depending on the exact routing
       protocols used.  Some of these attacks succeed only if the
       remote host does source address-based authentication; others
       can be used for more powerful attacks.

       A number of the attacks described below can also be used to
       accomplish denial of service by confusing the routing tables
       on a host or gateway.  The details are straight-forward
       corollaries of the penetration mechanisms, and will not be
       described further.

       3.1  Source Routing

       If available, the easiest mechanism to abuse is IP source
       routing.  Assume that the target host uses the reverse of
       the source route provided in a TCP open request for return
       traffic.  Such behavior is utterly reasonable; if the
       originator of the connection wishes to specify a particular
       path for some reason -- say, because the automatic route is
       dead -- replies may not reach the originator if a different
       path is followed.

       The attacker can then pick any IP source address desired,
       including that of a trusted machine on the target's local
       network.  Any facilities available to such machines become
       available to the attacker.

       Defenses
       It is rather hard to defend against this sort of attack.
       The best idea would be for the gateways into the local net
       to reject external packets that claim to be from the local
       net.  This is less practical than it might seem since some
       Ethernet3 network adapters receive their own transmissions,
       and this feature is relied upon by some higher-level
       protocols.  Furthermore, this solution fails completely if
       an organization has two trusted networks connected via a
       multi-organization backbone.  Other users on the backbone
       may not be trustable to the same extent that local users are
       presumed to be, or perhaps their vulnerability to outside
       attack is higher.  Arguably, such topologies should be
       avoided in any event.

       A simpler method might be to reject pre-authorized
       connections if source routing information was present.  This
       presumes that there are few legitimate reasons for using
       this IP option, especially for relatively normal operations.
       A variation on this defense would be to analyze the source
       route and accept it if only trusted gateways were listed;
       that way, the final gateway could be counted on to deliver
       the packet only to the true destination host.  The
       complexity of this idea is probably not worthwhile.
        __________

        3. Ethernet is a registered trademark of Xerox Corporation.

       Some protocols (i.e., Berkeley's rlogin and rsh) permit
       ordinary users to extend trust to remote host/user
       combinations.  In that case, individual users, rather than
       an entire system, may be targeted by source routing
       attacks.4 Suspicious gateways[14] will not help here, as the
       host being spoofed may not be within the security domain
       protected by the gateways.

       3.2  Routing Attacks

       The Routing Information Protocol[15] (RIP) is used to
       propagate routing information on local networks, especially
       broadcast media.  Typically, the information received is
       unchecked.  This allows an intruder to send bogus routing
       information to a target host, and to each of the gateways
       along the way, to impersonate a particular host.  The most
       likely attack of this sort would be to claim a route to a
       particular unused host, rather than to a network; this would
       cause all packets destined for that host to be sent to the
       intruder's machine.  (Diverting packets for an entire
       network might be too noticeable; impersonating an idle
       work-station is comparatively risk-free.)  Once this is
       done, protocols that rely on address-based authentication
       are effectively compromised.

       This attack can yield more subtle, and more serious,
       benefits to the attacker as well.  Assume that the attacker
       claims a route to an active host or workstation instead.
       All packets for that host will be routed to the intruder's
       machine for inspection and possible alteration.  They are
       then resent, using IP source address routing, to the
       intended destination.  An outsider may thus capture
       passwords and other sensitive data.  This mode of attack is
       unique in that it affects outbound calls as well; thus, a
       user calling out from the targeted host can be tricked into
       divulging a password.  Most of the earlier attacks discussed
       are used to forge a source address; this one is focused on
       the destination address.
       __________

        4. Permitting ordinary users to extend trust is probably
           wrong in any event, regardless of abuse of the
           protocols.  But such concerns are beyond the scope of
           this paper.

       Defenses
       A RIP attack is somewhat easier to defend against than the
       source-routing attacks, though some defenses are similar.  A
       paranoid gateway -- one that filters packets based on source
       or destination address -- will block any form of host-
       spoofing (including TCP sequence number attacks), since the
       offending packets can never make it through.  But there are
       other ways to deal with RIP problems.

       One defense is for RIP to be more skeptical about the routes
       it accepts.  In most environments, there is no good reason
       to accept new routes to your own local networks.  A router
       that makes this check can easily detect intrusion attempts.
       Unfortunately, some implementations rely on hearing their
       own broadcasts to retain their knowledge of directly-
       attached networks.  The idea, presumably, is that they can
       use other networks to route around local outages.  While
       fault-tolerance is in general a good idea, the actual
       utility of this technique is low in many environments
       compared with the risks.

       It would be useful to be able to authenticate RIP packets;
       in the absence of inexpensive public-key signature schemes,
       this is difficult for a broadcast protocol.  Even if it were
       done, its utility is limited; a receiver can only
       authenticate the immediate sender, which in turn may have
       been deceived by gateways further upstream.

       Even if the local routers don't implement defense
       mechanisms, RIP attacks carry another risk:  the bogus
       routing entries are visible over a wide area.  Any router
       (as opposed to host) that receives such data will
       rebroadcast it; a suspicious administrator almost anywhere
       on the local collection of networks could notice the
       anomaly.  Good log generation would help, but it is hard to
       distinguish a genuine intrusion from the routing instability
       that can accompany a gateway crash.

       3.3  Exterior Gateway Protocol

       The Exterior Gateway Protocol (EGP)[16] is intended for
       communications between the core gateways and so-called
       exterior gateways.  An exterior gateway, after going through
       a neighbor acquisition protocol, is periodically polled by
       the core; it responds with information about the networks it
       serves.  These networks must all be part of its autonomous
       system.  Similarly, the gateway periodically requests
       routing information from the core gateway.  Data is not
       normally sent except in response to a poll; furthermore,
       since each poll carries a sequence number that must be
       echoed by the response, it is rather difficult for an
       intruder to inject a false route update.  Exterior gateways
       are allowed to send exactly one spontaneous update between
       any two polls; this, too, must carry the sequence number of
       the last poll received.  It is thus comparatively difficult
       to interfere in an on-going EGP conversation.

       One possible attack would be to impersonate a second
       exterior gateway for the same autonomous system.  This may
       not succeed, as the core gateways could be equipped with a
       list of legitimate gateways to each autonomous system.  Such
       checks are not currently done, however.  Even if they were,
       they could be authenticated only by source IP address.

       A more powerful attack would be to claim reachability for
       some network where the real gateway is down.  That is, if
       gateway G normally handles traffic for network N, and G is
       down, gateway G' could advertise a route to that network.
       This would allow password capture by assorted mechanisms.
       The main defense against this attack is topological (and
       quite restrictive):  exterior gateways must be on the same
       network as the core; thus, the intruder would need to
       subvert not just any host, but an existing gateway or host
       that is directly on the main net.

       A sequence number attack, similar to those used against TCP,
       might be attempted; the difficulty here is in predicting
       what numbers the core gateway is using.  In TCP, one can
       establish arbitrary connections to probe for information; in
       EGP, only a few hosts may speak to the core.  (More
       accurately, the core could only speak to a few particular
       hosts, though as noted such checks are not currently
       implemented.)  It may thus be hard to get the raw data
       needed for such an attack.

       3.4  The Internet Control Message Protocol

       The Internet Control Message Protocol (ICMP)[17] is the
       basic network management tool of the TCP/IP protocol suite.
       It would seem to carry a rich potential for abuse.
       Surprisingly, ICMP attacks are rather difficult; still,
       there are often holes that may be exploited.

       The first, and most obvious target, is the ICMP Redirect
       message; it is used by gateways to advise hosts of better
       routes.  As such it can often be abused in the same way that
       RIP can be.  The complication is that a Redirect message
       must be tied to a particular, existing connection; it cannot
       be used to make an unsolicited change to the host's routing
       tables.  Furthermore, Redirects are only applicable within a
       limited topology; they may be sent only from the first
       gateway along the path to the originating host.  A later
       gateway may not advise that host, nor may it use ICMP
       Redirect to control other gateways.

       Suppose, though, that an intruder has penetrated a secondary
       gateway available to a target host, but not the primary one.
       (It may suffice to penetrate an ordinary host on the
       target's local network, and have it claim to be a gateway.)
       Assume further that the intruder wishes to set up a false
       route to trusted host T through that compromised secondary
       gateway.  The following sequence may then be followed.  Send
       a false TCP open packet to the target host, claiming to be
       from T.  The target will respond with its own open packet,
       routing it through the secure primary gateway.  While this
       is in transit, a false Redirect may be sent, claiming to be
       from the primary gateway, and referring to the bogus
       connection.  This packet will appear to be a legitimate
       control message; hence the routing change it contains will
       be accepted.  If the target host makes this change to its
       global routing tables, rather than just to the per-
       connection cached route, the intruder may proceed with
       spoofing host T.

       Some hosts do not perform enough validity checks on ICMP
       Redirect messages; in such cases, the impact of this attack
       becomes similar to RIP-based attacks.

       ICMP may also be used for targeted denial of service
       attacks.  Several of its messages, such as Destination
       Unreachable and Time to Live Exceeded, may be used to reset
       existing connections.  If the intruder knows the local and
       remote port numbers of a TCP connection, an ICMP packet
       aimed at that connection may be forged5.  Such information
       is sometimes available through the netstat service.

       A more global denial of service attack can be launched by
       sending a fraudulent Subnet Mask Reply message.  Some hosts
       will accept any such message, whether they have sent a query
       or not; a false one could effectively block all
       communications with the target host.
       __________

        5. In fact, such programs are available today; they are
           used as administrative tools to reset hung TCP
           connections.

       Defenses
       Most ICMP attacks are easy to defend against with just a
       modicum of paranoia.  If a host is careful about checking
       that a message really does refer to a particular connection,
       most such attacks will not succeed.  In the case of TCP,
       this includes verifying that the ICMP packet contains a
       plausible sequence number in the returned-packet portion.
       These checks are less applicable to UDP, though.

       A defense against Redirect attacks merits additional
       attention, since such attacks can be more serious.
       Probably, the best option is to restrict route changes to
       the specified connection; the global routing table should
       not be modified in response to ICMP Redirect messages6.

       Finally, it is worth considering whether ICMP Redirects are
       even useful in today's environment.  They are only usable on
       local networks with more than one gateway to the outside
       world.  But it is comparatively easy to maintain complete
       and correct local routing information.  Redirect messages
       would be most useful from the core gateways to local
       exterior gateways, as that would allow such local gateways
       to have less than complete knowledge of the Internet; this
       use is disallowed, however.

       Subnet Mask attacks can be blocked if the Reply packet is
       honored only at the appropriate time.  In general, a host
       wants to see such a message only at boot time, and only if
       it had issued a query; a stale reply, or an unsolicited
       reply, should be rejected out of hand.  There is little
       defense against a forged reply to a genuine Subnet Mask
       query, as a host that has sent such a query typically has
       few resources with which to validate the response.  If the
       genuine response is not blocked by the intruder, though, the
       target will receive multiple replies; a check to ensure that
       all replies agree would guard against administrative errors
       as well.
       __________

        6. This has other benefits as well, especially in
           environments where ICMP-initiated route changes are not
           timed out.  The author has seen situations where RIP
           instability following a gateway crash has led to
           erroneous ICMP Redirect messages.  These had the effect
           of permanently corrupting the routing tables on other
           hosts.

       4.  THE "AUTHENTICATION" SERVER

       As an alternative to address-based authentication, some
       implementations use the Authentication Server[18].  A server
       that wishes to know the identity of its client may contact
       the client host's Authentication Server7, and ask it for
       information about the user owning a particular connection.
       This method is inherently more secure than simple address-
       based authentication, as it uses a second TCP connection not
       under control of the attacker.  It thus can defeat sequence
       number attacks and source routing attacks.  There are
       certain risks, however.

       The first, and most obvious, is that not all hosts are
       competent to run authentication servers.  If the client host
       is not secure, it does not matter who the user is claimed to
       be; the answer cannot be trusted.  Second, the
       authentication message itself can be compromised by routing
       table attacks.  If RIP has been used to alter the target's
       idea of how to reach some host, the authentication query
       will rely on the same altered routing data.  Finally, if the
       target host is down, a variant on the TCP sequence number
       attack may be used; after the server sends out a TCP open
       request to the presumed authentication server, the attacker
       can complete the open sequence and send a false reply.  If
       the target runs a netstat server, this is even easier; as
       noted, netstat will often supply the necessary sequence
       numbers with no need to guess.

       A less-obvious risk is that a fake authentication server can
       always reply "no".  This constitutes a denial of service
       attack.

       Defenses
       A server that wishes to rely on another host's idea of a
       user should use a more secure means of validation, such as
       the Needham-Schroeder algorithm[20][21][22].  TCP by itself
       is inadequate.
       __________

        7. The Internet Activities Board does not currently
           recommend the Authentication Server for
           implementation[19].  However, the decision was not made
           because of security problems[5].

       5.  HERE BE DRAGONS

       Some protocols, while not inherently flawed, are
       nevertheless susceptible to abuse.  A wise implementor would
       do well to take these problems into account when providing
       the service.

       5.1  The "Finger" Service

       Many systems implement a finger service[23].  This server
       will display useful information about users, such as their
       full names, phone numbers, office numbers, etc.
       Unfortunately, such data provides useful grist for the mill
       of a password cracker.[24] By running such a service, a
       system administrator is giving away this data.

       5.2  Electronic Mail

       Electronic mail is probably the most valuable service on the
       Internet.  Nevertheless, it is quite vulnerable to misuse.
       As normally implemented[25][26], the mail server provides no
       authentication mechanisms.  This leaves the door wide open
       to faked messages.  RFC 822 does support an Encrypted header
       line, but this is not widely used.  (However, see RFC
       1040[27] for a discussion of a proposed new encryption
       standard for electronic mail.)

       5.2.1  The Post Office Protocol

       The The Post Office Protocol (POP)[28] allows a remote user
       to retrieve mail stored on a central server machine.
       Authentication is by means of a single command containing
       both the user name and the password.  However, combining the
       two on a single command mandates the use of conventional
       passwords.  And such passwords are becoming less popular;
       they are too vulnerable to wire-tappers, intentional or
       accidental disclosure, etc.

       As an alternative, many sites are adopting "one-time
       passwords"8.  With one-time passwords, the host and some
       device available to the user share a cryptographic key.  The
       host issues a random challenge; both sides encrypt this
       number, and the user transmits it back to the host.  Since
       __________

        8. One-time passwords were apparently first used for
           military IFF (Identification Friend or Foe) systems[29].

       the challenge is random, the reply is unique to that
       session, thereby defeating eavesdroppers.  And since the
       user does not know the key -- it is irretrievably stored in
       the device -- the password cannot be given away without
       depriving the user of the ability to log in.

       The newest version of POP[30] has split the user name and
       password into two commands, which is useful.  However, it
       also defines an optional mechanism for preauthenticated
       connections, typically using Berkeley's mechanisms.
       Commendably, the security risks of this variant are
       mentioned explicitly in the document.

       5.2.2  PCMAIL

       The PCMAIL protocol[31] uses authentication mechanisms
       similar to those in POP2.  In one major respect, PCMAIL is
       more dangerous:  it supports a password-change command.
       This request requires that both the old and new passwords be
       transmitted unencrypted.

       5.3  The Domain Name System

       The Domain Name System (DNS)[32][33] provides for a
       distributed database mapping host names to IP addresses.  An
       intruder who interferes with the proper operation of the DNS
       can mount a variety of attacks, including denial of service
       and password collection.  There are a number of
       vulnerabilities.

       In some resolver implementations, it is possible to mount a
       sequence number attack against a particular user.  When the
       target user attempts to connect to a remote machine, an
       attacker can generate a domain server response to the
       target's query.  This requires knowing both the UDP port
       used by the client's resolver and the DNS sequence number
       used for the query.  The latter is often quite easy to
       obtain, though, since some resolvers always start their
       sequence numbers with 0.  And the former may be obtainable
       via netstat or some analogous host command.

       A combined attack on the domain system and the routing
       mechanisms can be catastrophic.  The intruder can intercept
       virtually all requests to translate names to IP addresses,
       and supply the address of a subverted machine instead; this
       would allow the intruder to spy on all traffic, and build a
       nice collection of passwords if desired.

       For this reason, domain servers are high-value targets; a
       sufficiently determined attacker might find it useful to
       take over a server by other means, including subverting the
       machine one is on, or even physically interfering with its
       link to the Internet.  There is no network defense against
       the former, which suggests that domain servers should only
       run on highly secure machines; the latter issue may be
       addressed by using authentication techniques on domain
       server responses.

       The DNS, even when functioning correctly, can be used for
       some types of spying.  The normal mode of operation of the
       DNS is to make specific queries, and receive specific
       responses.  However, a zone transfer (AXFR) request exists
       that can be used to download an entire section of the
       database; by applying this recursively, a complete map of
       the name space can be produced.  Such a database represents
       a potential security risk; if, for example, an intruder
       knows that a particular brand of host or operating system
       has a particular vulnerability, that database can be
       consulted to find all such targets.  Other uses for such a
       database include espionage; the number and type of machines
       in a particular organization, for example, can give away
       valuable data about the size of the organization, and hence
       the resources committed to a particular project.

       Fortunately, the domain system includes an error code for
       "refused"; an administrative prohibition against such zone
       transfers is explicitly recognized as a legitimate reason
       for refusal.  This code should be employed for zone transfer
       requests from any host not known to be a legitimate
       secondary server.  Unfortunately, there is no authentication
       mechanism provided in the AXFR request; source address
       authentication is the best that can be done.

       Recently, a compatible authentication extension to the DNS
       has been devised at M.I.T.  The Hesiod name server[34] uses
       Kerberos[35] tickets to authenticate queries and responses.
       The additional information section of the query carries an
       encrypted ticket, which includes a session key; this key,
       known only to Hesiod and the client, is used to compute a
       cryptographic checksum of the both the query and the
       response.  These checksums are also sent in the additional
       information field.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              NIA074 / File 03

               Security Problems in the TCP/IP Protocol Suite

                              Part II of II

                              S.M. Bellovin

                          AT&T Bell Laboratories


       5.4  The File Transfer Protocol

       The File Transfer Protocol (FTP)[36] itself is not flawed.
       However, a few aspects of the implementation merit some
       care.

       5.4.1  FTP Authentication

       FTP relies on a login and password combination for
       authentication.  As noted, simple passwords are increasingly
       seen as inadequate; more and more sites are adopting one-
       time passwords.  Nothing in the FTP specification precludes
       such an authentication method.  It is vital, however, that
       the "331" response to a USER subcommand be displayed to
       the user; this message would presumably contain the
       challenge.  An FTP implementation that concealed this
       response could not be used in this mode; if such
       implementations are (or become) common, it may be necessary
       to use a new reply code to indicate that the user must see
       the content of the challenge.

       5.4.2  Anonymous FTP

       A second problem area is "anonymous FTP".  While not
       required by the FTP specification, anonymous FTP is a
       treasured part of the oral tradition of the Internet.
       Nevertheless, it should be implemented with care.

       One part of the problem is the implementation technique
       chosen.  Some implementations of FTP require creation of a
       partial replica of the directory tree; care must be taken to
       ensure that these files are not subject to compromise.  Nor
       should they contain any sensitive information, such as
       encrypted passwords.

       The second problem is that anonymous FTP is truly anonymous;
       there is no record of who has requested what information.
       Mail-based servers will provide that data; they also provide
       useful techniques for load-limiting9, background transfers,
       etc.

       5.5  Simple Network Management Protocol

       The Simple Network Management Protocol (SNMP)[37] has
       recently been defined to aid in network management.
       Clearly, access to such a resource must be heavily
       protected.  The RFC states this, but also allows for a null
        __________

        9. Recently, a host was temporarily rendered unusable by
           massive numbers of FTP requests for a popular technical
           report.  If this were deliberate, it would be considered
           a successful denial of service attack.

       authentication service; this is a bad idea.  Even a "read-
       only" mode is dangerous; it may expose the target host to
       netstat-type attacks if the particular Management
       Information Base (MIB)[38] used includes sequence numbers.
       (The current standardized version does not; however, the MIB
       is explicitly declared to be extensible.)

       5.6  Remote Booting

       Two sets of protocols are used today to boot diskless
       workstations and gateways, Reverse ARP (RARP)[39] with the
       Trivial File Transfer Protocol (TFTP)[40] and BOOTP[41] with
       TFTP.  A system being booted is a tempting target; if one
       can subvert the boot process, a new kernel with altered
       protection mechanisms can be substituted.  RARP-based
       booting is riskier because it relies on Ethernet-like
       networks, with all the vulnerabilities adhering thereto.
       One can achieve a modest improvement in security by ensuring
       that the booting machine uses a random number for its UDP
       source port; otherwise, an attacker can impersonate the
       server and send false DATA packets.

       BOOTP adds an additional layer of security by including a
       4-byte random transaction id.  This prevents an attacker
       from generating false replies to a workstation known to be
       rebooting.  It is vital that these numbers indeed be random;
       this can be difficult in a system that is freshly powered
       up, and hence with little or no unpredictable state.  Care
       should be taken when booting through gateways; the more
       networks traversed, the greater the opportunity for
       impersonation.

       The greatest measure of protection is that normally, the
       attacker has only a single chance; a system being booted
       does not stay in that state.  If, however, communications
       between the client and the standard server may be
       interrupted, larger-scale attacks may be mounted.

       6.  TRIVIAL ATTACKS

       A few attacks are almost too trivial to mention;
       nevertheless, completeness demands that they at least be
       noted.

       6.1  Vulnerability of the Local Network

       Some local-area networks, notably the Ethernet networks, are
       extremely vulnerable to eavesdropping and host-spoofing.  If
       such networks are used, physical access must be strictly
       controlled.  It is also unwise to trust any hosts on such
       networks if any machine on the network is accessible to
       untrusted personnel, unless authentication servers are used.

       If the local network uses the Address Resolution Protocol
       (ARP)[42] more subtle forms of host-spoofing are possible.
       In particular, it becomes trivial to intercept, modify, and
       forward packets, rather than just taking over the host's
       role or simply spying on all traffic.

       It is possible to launch denial of service attacks by
       triggering broadcast storms.  There are a variety of ways to
       do this; it is quite easy if most or all of the hosts on the
       network are acting as gateways.  The attacker can broadcast
       a packet destined for a non-existent IP address.  Each host,
       upon receiving it, will attempt to forward it to the proper
       destination.  This alone will represent a significant amount
       of traffic, as each host will generate a broadcast ARP query
       for the destination.  The attacker can follow up by
       broadcasting an ARP reply claiming that the broadcast
       Ethernet address is the proper way to reach that
       destination.  Each suspectible host will then not only
       resend the bogus packet, it will also receive many more
       copies of it from the other suspectible hosts on the
       network.

       6.2  The Trivial File Transfer Protocol

       TFTP[40] permits file transfers without any attempt at
       authentication.  Thus, any publicly-readable file in the
       entire universe is accessible.  It is the responsibility of
       the implementor and/or the system administrator to make that
       universe as small as possible.

       6.3  Reserved Ports

       Berkeley-derived TCPs and UDPs have the notion of a
       "privileged port".  That is, port numbers lower than 1024
       may only be allocated to privileged processes.  This
       restriction is used as part of the authentication mechanism.
       However, neither the TCP nor the UDP specifications contain
       any such concept, nor is such a concept even meaningful on a
       single-user computer.  Administrators should never rely on
       the Berkeley authentication schemes when talking to such
       machines.

       7.  COMPREHENSIVE DEFENSES

       Thus far, we have described defenses against a variety of
       individual attacks.  Several techniques are broad-spectrum
       defenses; they may be employed to guard against not only
       these attacks, but many others as well.

       7.1  Authentication

       Many of the intrusions described above succeed only because
       the target host uses the IP source address for
       authentication, and assumes it to be genuine.
       Unfortunately, there are sufficiently many ways to spoof
       this address that such techniques are all but worthless.
       Put another way, source address authentication is the
       equivalent of a file cabinet secured with an S100 lock; it
       may reduce the temptation level for more-or-less honest
       passers-by, but will do little or nothing to deter anyone
       even slightly serious about gaining entry.

       Some form of cryptographic authentication is needed.  There
       are several possible approaches.  Perhaps the best-known is
       the Needham-Schroeder algorithm[20][21][22].  It relies on
       each host sharing a key with an authentication server; a
       host wishing to establish a connection obtains a session key
       from the authentication server and passes a sealed version
       along to the destination.  At the conclusion of the dialog,
       each side is convinced of the identity of the other.
       Versions of the algorithm exist for both private-key and
       public-key[43] cryptosystems.

       How do these schemes fit together with TCP/IP?  One answer
       is obvious:  with them, preauthenticated connections can be
       implemented safely; without them, they are quite risky.  A
       second answer is that the DNS provides an ideal base for
       authentication systems, as it already incorporates the
       necessary name structure, redundancy, etc.  To be sure, key
       distribution responses must be authenticated and/or
       encrypted; as noted, the former seems to be necessary in any
       event.

       In some environments, care must be taken to use the session
       key to encrypt the entire conversation; if this is not done,
       an attacker can take over a connection via the mechanisms
       described earlier.

       7.2  Encryption

       Suitable encryption can defend against most of the attacks
       outlined above.  But encryption devices are expensive, often
       slow, hard to administer, and uncommon in the civilian
       sector.  There are different ways to apply encryption; each
       has its strengths and weaknesses.  A comprehensive treatment
       of encryption is beyond the scope of this paper; interested
       readers should consult Voydock and Kent[44] or Davies and
       Price[45].

       Link-level encryption -- encrypting each packet as it leaves
       the host computer -- is an excellent method of guarding
       against disclosure of information.  It also works well
       against physical intrusions; an attacker who tapped in to an
       Ethernet cable, for example, would not be able to inject
       spurious packets.  Similarly, an intruder who cut the line
       to a name server would not be able to impersonate it.  The
       number of entities that share a given key determines the
       security of the network; typically, a key distribution
       center will allocate keys to each pair of communicating
       hosts.

       Link-level encryption has some weaknesses, however.
       Broadcast packets are difficult to secure; in the absence of
       fast public-key cryptosystems, the ability to decode an
       encrypted broadcast implies the ability to send such a
       broadcast, impersonating any host on the network.
       Furthermore, link-level encryption, by definition, is not
       end-to-end; security of a conversation across gateways
       implies trust in the gateways and assurance that the full
       concatenated internet is similarly protected.  (This latter
       constraint may be enforced administratively, as is done in
       the military sector.)  If such constraints are not met,
       tactics such as source-routing attacks or RIP-spoofing may
       be employed.  Paranoid gateways can be deployed at the
       entrance to security domains; these might, for example,
       block incoming RIP packets or source-routed packets.

       Many portions of the DARPA Internet employ forms of link
       encryption.  All Defense Data Network (DDN) IMP-to-IMP
       trunks use DES encryption, even for non-classified traffic;
       classified lines use more secure cryptosystems[46].  These,
       however, are point-to-point lines, which are comparatively
       easy to protect.

       A multi-point link encryption device for TCP/IP is the
       Blacker Front End (BFE)[47].  The BFE looks to the host like
       an X.25 DDN interface, and sits between the host and the
       actual DDN line.  When it receives a call request packet
       specifying a new destination, it contacts an Access Control
       Center (ACC) for permission, and a Key Distribution Center
       (KDC) for cryptographic keys.  If the local host is denied
       permission to talk to the remote host, an appropriate
       diagnostic code is returned.  A special "Emergency Mode"
       is available for communications to a restricted set of
       destinations at times when the link to the KDC or ACC is not
       working.

       The permission-checking can, to some extent, protect against
       the DNS attacks described earlier.  Even if a host has been
       mislead about the proper IP address for a particular
       destination, the BFE will ensure that a totally unauthorized
       host does not receive sensitive data.  That is, assume that
       a host wishes to send Top Secret data to some host foo.  A
       DNS attack might mislead the host into connecting to
       penetrated host 4.0.0.4, rather than 1.0.0.1.  If 4.0.0.4 is
       not cleared for Top Secret material, or is not allowed
       communications with the local host, the connection attempt
       will fail.  To be sure, a denial of service attack has taken
       place; this, in the military world, is far less serious than
       information loss.

       The BFE also translates the original ("Red") IP address to
       an encrypted ("Black") address, using a translation table
       supplied by the ACC.  This is done to foil traffic analysis
       techniques, the bane of all multi-point link encryption
       schemes.

       End-to-end encryption, above the TCP level, may be used to
       secure any conversation, regardless of the number of hops or
       the quality of the links.  This is probably appropriate for
       centralized network management applications, or other
       point-to-point transfers.  Key distribution and management
       is a greater problem, since there are more pairs of
       correspondents involved.  Furthermore, since encryption and
       decryption are done before initiation or after termination
       of the TCP processing, host-level software must arrange for
       the translation; this implies extra overhead for each such
       conversation10.

       End-to-end encryption is vulnerable to denial of service
       attacks, since fraudulently-injected packets can pass the
       __________

       10. We are assuming that TCP is handled by the host, and not
           by a front-end processor.

       TCP checksum tests and make it to the application.  A
       combination of end-to-end encryption and link-level
       encryption can be employed to guard against this.  An
       intriguing alternative would be to encrypt the data portion
       of the TCP segment, but not the header; the TCP checksum
       would be calculated on the cleartext, and hence would detect
       spurious packets.  Unfortunately, such a change would be
       incompatible with other implementations of TCP, and could
       not be done transparently at application level.

       Regardless of the method used, a major benefit of encrypted
       communications is the implied authentication they provide.
       If one assumes that the key distribution center is secure,
       and the key distribution protocols are adequate, the very
       ability to communicate carries with it a strong assurance
       that one can trust the source host's IP address for
       identification.

       This implied authentication can be especially important in
       high-threat situations.  A routing attack can be used to
       "take over" an existing connection; the intruder can
       effectively cut the connection at the subverted machine,
       send dangerous commands to the far end, and all the while
       translate sequence numbers on packets passed through so as
       to disguise the intrusion.

       It should be noted, of course, that any of these encryption
       schemes provide privacy.  Often that is the primary goal of
       such systems.

       7.3  Trusted Systems

       Given that TCP/IP is a Defense Department protocol suite, it
       is worth asking to what extent the Orange Book[48] and Red
       Book[49] criteria would protect a host from the attacks
       described above.  That is, suppose that a target host (and
       the gateways!) were rated B1 or higher.  Could these attacks
       succeed?  The answer is a complex one, and depends on the
       assumptions we are willing to make.  In general, hosts and
       routers rated at B2 or higher are immune to the attacks
       described here, while C2-level systems are susceptible.
       B1-level systems are vulnerable to some of these attacks,
       but not all.

       In order to understand how TCP/IP is used in secure
       environments, a brief tutorial on the military security
       model is necessary.  All objects in the computer system,
       such as files or network channels, and all data exported
       from them, must have a label indicating the sensitivity of
       the information in them.  This label includes hierarchical
       components (i.e., Confidential, Secret, and Top Secret) and
       non-hierarchical components.  Subjects -- i.e., processes
       within the computer system -- are similarly labeled.  A
       subject may read an object if its label has a higher or
       equal hierarchical level and if all of the object's non-
       hierarchical components are included in the subject's label.
       In other words, the process must have sufficient clearance
       for the information in a file.  Similarly, a subject may
       write to an object if the object has a higher or equal level
       and the object's non-hierarchical components include all of
       those in the subject's level.  That is, the sensitivity
       level of the file must be at least as high as that of the
       process.  If it were not, a program with a high clearance
       could write classified data to a file that is readable by a
       process with a low security clearance.

       A corollary to this is that for read/write access to any
       file, its security label must exactly match that of the
       process.  The same applies to any form of bidirectional
       interprocess communication (i.e., a TCP virtual circuit):
       both ends must have identical labels.

       We can now see how to apply this model to the TCP/IP
       protocol suite.  When a process creates a TCP connection,
       that connection is given the process's label.  This label is
       encoded in the IP security option.  The remote TCP must
       ensure that the label on received packets matches that of
       the receiving process.  Servers awaiting connections may be
       eligible to run at multiple levels; when the connection is
       instantiated, however, the process must be forced to the
       level of the connection request packet.

       IP also makes use of the security option[50].  A packet may
       not be sent over a link with a lower clearance level.  If a
       link is rated for Secret traffic, it may carry Unclassified
       or Confidential traffic, but it may not carry Top Secret
       data.  Thus, the security option constrains routing
       decisions.  The security level of a link depends on its
       inherent characteristics, the strength of any encryption
       algorithms used, the security levels of the hosts on that
       network, and even the location of the facility.  For
       example, an Ethernet cable located in a submarine is much
       more secure than if the same cable were running through a
       dormitory room in a university.

       Several points follow from these constraints.  First, TCP-
       level attacks can only achieve penetration at the level of
       the attacker.  That is, an attacker at the Unclassified
       level could only achieve Unclassified privileges on the
       target system, regardless of which network attack was
       used11.  Incoming packets with an invalid security marking
       would be rejected by the gateways.

       Attacks based on any form of source-address authentication
       should be rejected as well.  The Orange Book requires that
       systems provide secure means of identification and
       authentication; as we have shown, simple reliance on the IP
       address is not adequate.  As of the B1 level, authentication
       information must be protected by cryptographic checksums
       when transmitted from machine to machine12.

       The authentication server is still problematic; it can be
       spoofed by a sequence number attack, especially if netstat
       is available.  This sort of attack could easily be combined
       with source routing for full interactive access.  Again,
       cryptographic checksums would add significant strength.

       B1-level systems are not automatically immune from routing
       attacks; RIP-spoofing could corrupt their routing tables
       just as easily.  As seen, that would allow an intruder to
       capture passwords, perhaps even some used on other trusted
       systems.  To be sure, the initial penetration is still
       restricted by the security labelling, but that may not block
       future logins captured by these means.

       Routing attacks can also be used for denial of service.
       Specifically, if the route to a secure destination is
       changed to require use of an insecure link, the two hosts
       will not be able to communicate.  This change would probably
       be detected rather quickly, though, since the gateway that
       noticed the misrouted packet would flag it as a security
       problem.

       At the B2 level, secure transmission of routing control
       information is required.  Similar requirements apply to
       other network control information, such as ICMP packets.

       __________

       11. We are assuming, of course, that the penetrated system
           does not have bugs of its own that would allow further
           access.

       12. More precisely, user identification information must be
           protected to an equal extent with data sensitivity
           labels.  Under certain circumstances, described in the
           Red Book, cryptographic checks may be omitted.  In
           general, though, they are required.

       Several attacks we have described rely on data derived from
       "information servers", such as netstat and finger.  While
       these, if carefully done, may not represent a direct
       penetration threat in the civilian sense, they are often
       seen to represent a covert channel that may be used to leak
       information.  Thus, many B-division systems do not implement
       such servers.

       In a practical sense, some of the technical features we have
       described may not apply in the military world.
       Administrative rules[51] tend to prohibit risky sorts of
       interconnections; uncleared personnel are not likely to have
       even indirect access to systems containing Top Secret data.
       Such rules are, most likely, an accurate commentary on
       anyone's ability to validate any computer system of non-
       trivial size.

        8.  CONCLUSIONS

       Several points are immediately obvious from this analysis.
       The first, surely, is that in general, relying on the IP
       source address for authentication is extremely dangerous13.
       Fortunately, the Internet community is starting to accept
       this on more than an intellectual level.  The Berkeley
       manuals[3] have always stated that the authentication
       protocol was very weak, but it is only recently that serious
       attempts (i.e., Kerberos[35] and SunOS 4.0's DES
       authentication mode[52]) have been made to correct the
       problem.  Kerberos and SunOS 4.0 have their weaknesses, but
       both are far better than their predecessor.  More recently,
       an extension to the Network Time Protocol (NTP)[53] has been
       proposed that includes a cryptographic checksum[54].

       A second broad class of problems is sequence number attacks.
       If a protocol depends on sequence numbers -- and most do --
       it is vital that they be chosen unpredictably.  It is worth
       considerable effort to ensure that these numbers are not
       knowable even to other users on the same system.
       __________

       13. There are some exceptions to this rule.  If the entire
           network, and all of its components (hosts, gateways,
           cables, etc.) are physically protected, and if all of
           the operating systems are sufficiently secure, there
           would seem to be little risk.

       We may generalize this by by stating that hosts should not
       give away knowledge gratuitously.  A finger server, for
       example, would be much safer if it only supplied information
       about a known user, rather than supplying information about
       everyone logged on.  Even then, some censorship might be
       appropriate; a refusal to supply the last login date and
       other sensitive information would be appropriate if the
       account was not used recently.  (Never-used accounts often
       have simple default passwords.  Infrequently-used accounts
       are often set up less carefully by the owner.)  We have also
       seen how netstat may be abused; indeed, the combination of
       netstat with the authentication server is the single
       strongest attack using the standardized Internet protocols.

       Finally, network control mechanisms are dangerous, and must
       be carefully guarded.  Static routes are not feasible in a
       large-scale network, but intelligent use of default routes
       and verifiable point-to-point routing protocols (i.e., EGP)
       are far less vulnerable than broadcast-based routing.

       9.  ACKNOWLEDGEMENTS

       Dave Presotto, Bob Gilligan, Gene Tsudik, and especially
       Deborah Estrin made a number of useful suggestions and
       corrections to a draft of this paper.

                                REFERENCES

        1. E.J. Feinler, O.J. Jacobsen, M.K. Stahl, C.A. Ward, eds.
           DDN Protocol Handbook.  DDN Network Information Center,
           SRI International, 1985.

        2. Comer, D.  Internetworking with TCP/IP: Principles,
           Protocols, and Architecture.  Prentice Hall, 1988

        3. Computer Systems Research Group.  UNIX User's Reference
           Manual (URM).  4.3 Berkeley Software Distribution
           Virtual Vax-11 Version.  Computer Science Division,
           Department of Electrical Engineering and Computer
           Science, University of California, Berkeley.  1986.

        4. Spafford, E.H.  The Internet Worm Program: An Analysis.
           Purdue Technical Report CSD-TR-823, Department of
           Computer Sciences Purdue University, West Lafayette, IN.
           1988

        5. Seeley, D.  A Tour of the Worm.  Department of Computer
           Science, University of Utah.  1988.

        6. Eichin, M. and Rochlis, J.  With Microscope and
           Tweezers:  An Analysis of the Internet Virus of November
           1988.  Massachussetts Institute of Technology, 1988.

        7. Morris, R.T.  1985.  A Weakness in the 4.2BSD UNIX
           TCP/IP Software.  Computing Science Technical Report No.
           117, AT&T Bell Laboratories, Murray Hill, New Jersey.

        8. Reynolds, J.K., and J. Postel.  Assigned Numbers.  RFC
           990, 1986

        9. Mills, D.L.  Internet Delay Experiments, RFC 889, 1983.

       10. Blum, M. and Micali, S.  "How to Generate
           Cryptographically Strong Sequences of Pseudo-Random
           Bits".  SIAM J Computing, vol. 13, no. 4, pp. 850-864,
           Nov. 1984.

       11. US Federal Information Processing Standards Publication
           (FIPS PUB) 46, Data Encryption Standard, 15 January
           1977.

       12. US Federal Information Processing Standards Publication
           (FIPS PUB) 81.  DES Modes of Operation, 2 December 1980.

       13. Bishop, M.  An Application of a Fast Data Encryption
           Standard Implementation.  Technical Report PCS-TR88-138,
           Department of Mathematics and Computer Science,
           Dartmouth College, Hanover, NH.  1988.

       14. Mogul, J.  "Simple and Flexible Datagram Access
           Controls for UNIX-based Gateways", Proceedings, Summer
           USENIX, 1989, Baltimore, Maryland (to appear).

       15. Hedrick, C.  Routing Information Protocol.  RFC 1058,
           1988.

       16. Mills, D.L.  Exterior Gateway Protocol Formal
           Specification.  RFC 904, 1984.

       17. Postel, J.  Internet Control Message Protocol.  RFC 792,
           1981.

       18. St. Johns, M.  Authentication Server.  RFC 931, 1985.

       19. Defense Advanced Research Projects Agency, Internet
           Activities Board.  IAB Official Protocol Standards.  RFC
           1083, 1988

       19. Postel, J.  Private communication.  1989.

       20. Needham, R.M. and Schroeder, M.D.  "Using Encryption
           for Authentication in Large Networks of Computers".
           Communications of the ACM, vol. 21, no. 12, pp. 993-999,
           December 1978.

       21. Denning, D.E. and Sacco, G.M.  "Timestamps in Key
           Distribution Protocols", Communications of the ACM,
           vol. 24, no. 8, pp. 533-536, August 1981.

       22. Needham, R.M. and Schroeder, M.D.  "Authentication
           Revisited", Operating Systems Review, vol. 21, no. 1,
           p. 7, January 1987.

       23. Harrenstien, K.  NAME/FINGER Protocol, RFC 742, 1977.

       24. Grampp, F.T. and Morris, R.H.  "UNIX Operating System
           Security", AT&T Bell Laboratories Technical Journal,
           vol. 63, no. 8, part 2, October, 1984.

       25. Crocker, D.  Standard for the Format of ARPA-Internet
           Text Messages.  RFC 822, 1982.

       26. Postel, J.  Simple Mail Transfer Protocol.  RFC 821,
           1982.

       27. Linn, J.  Privacy Enhancement for Internet Electronic
           Mail: Part I: Message Encipherment and Authentication
           Procedures.  RFC 1040, 1988.

       28. Butler, M.; Postel, J.B.; Chase, D.; Goldberger, J.;
           Reynolds, J.K.  Post Office Protocol - Version 2.  RFC
           937, 1985.

       29. Diffie, W.  "The First Ten Years of Public Key
           Cryptography".  Proc. IEEE, vol. 76, no. 5, pp. 560-
           577, May 1988.

       30. Rose, M.  Post Office Protocol - Version 3.  RFC 1081,
           1988

       31. Lambert, M.L.  PCMAIL: A Distributed Mail System for
           Personal Computers.  RFC 1056, 1988

       32. Mockapetris, P.  Domain Names - Concepts and Facilities.
           RFC 1034, 1987.

       33. Mockapetris, P.  Domain Names - Implementations and
           Specifications.  RFC 1035, 1987.

       34. Dyer, S.P.  "Hesiod", Proceedings, Winter USENIX,
           1988, Dallas, Texas.

       35. Steiner, J.G, Neuman, C., Schiller, J.I.  "Kerberos: An
           Authentication Service for Open Network Systems",
           Proceedings, Winter USENIX, 1988, Dallas, Texas.

       36. Postel, J.  File Transfer Protocol.  RFC 959, 1985.

       37. Case, J., Fedor, M., Schoffstall, J., and Davin, J.  A
           Simple Network Management Protocol.  RFC 1067, 1988.

       38. McCloghrie, K. and Rose, M.  Management Information Base
           for Network Management of TCP/IP-based Internets.  RFC
           1066.  1988.

       39. Finlayson, R.; Mann, T.; Mogul, J.; Theimer, M.  Reverse
           Address Resolution Protocol.  RFC 903, 1984.

       40. Sollins, K.R.  The TFTP Protocol (Revision 2).  RFC 783,
           1981.

       41. Croft, W.J.; Gilmore, J.  Bootstrap Protocol.  RFC 951,
           1985.

       42. Plummer, D.C.  An Ethernet Address Resolution Protocol.
           RFC 826, 1982.

       43. Diffie, W. and Hellman, M.E.  "New Directions in
           Cryptography."  IEEE Transactions on Information
           Theory, vol. IT-22, no. 6, pp. 644-654.

       44. Voydock, V.L. and Kent, S.T.  "Security Mechanisms in
           High-Level Network Protocols".  ACM Computer Surveys,
           vol. 15, no. 2, pp. 135-171, June 1983.

       45. Davies, D.W. and Price, W.L.  Security for Computer
           Networks: An Introduction to Data Security in
           Teleprocessing and Electronic Funds Transfer.  Wiley.
           1984.

       46. Defense Communications Agency.  Defense Data Network
           Subscriber Security Guide.  1983.

       47. "Blacker Front End Interface Control Document", in DDN
           Protocol Handbook.  DDN Network Information Center, SRI
           International, vol. 1, 1985.

       48. DoD Computer Security Center.  DoD Trusted Computer
           System Evaluation Criteria, 1983, CSC-STD-001-83.

       49. National Computer Security Center.  Trusted Network
           Interpretation of the Trusted Computer System Evaluation
           Criteria.  NCSC-TG-005, Version 1, July 31, 1987.

       50. St. Johns, M.  Draft Revised IP Security Option.  RFC
           1038, 1988.

       51. DoD Computer Security Center.  Technical Rationale
           Behind CSC-STD-003-85: Computer Security Requirements,
           CSC-STD-004-83, 1983.

       52. Taylor, B. and Goldberg, D.  "Secure Networking in the
           Sun Environment".  Proceedings, Summer USENIX, 1986,
           Atlanta, Georgia.

       53. Mills, D.L.  Network Time Protocol (Version 1)
           Specification and Implementation.  RFC 1059, 1988.

       54. Mills, D.L.  Mailing list message
           <[e-mail]>, January 19, 1989.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



                The Design of a Secure Internet Gateway

                             Bill Cheswick
                           10 September 1991
                         TECHNICAL MEMORANDUM

Abstract
--------
The Internet supports a vast and growing community of computer users
around the world.
Unfortunately, this network can provide anonymous access to this
community by unscrupulous, careless, or dangerous people.
On any given Internet there is a certain percentage of poorly-maintained
systems.
AT&T has a large internal
Internet that we wish to protect from outside attacks, while providing
useful services between the two.

This paper describes our Internet gateway.  It is an application-level
gateway that passes mail and many of the common Internet services
between our internal machines and the Internet.  This is accomplished
without IP connectivity using a pair of machines: a trusted internal
machine and an untrusted external gateway.  These are connected by a private
link.  The internal machine provides a few carefully-guarded services
to the external gateway.  This configuration helps protect the internal
internet even if the external machine is fully compromised.

This is a slightly-updated version of the paper presented at the 1990
summer Usenix at Anaheim.

Introduction
------------
The design of a Corporate gateway to the Internet must deal with the
classical tradeoff between security and convenience.  Most institutions
opt for convenience and use a simple router between their internal
internets and the rest of the world.  This is dangerous.
Strangers on the Internet can reach and test every internal machine.
With workstations sitting on many desks, system administration is
often decentralized and neglected.  Passwords are weak or missing.
A professor or researcher often may install the operating system
and forget it, leaving well-known security holes uncorrected.
For example, a sweep of 1,300 machines inside Bell Labs around
the time of the Internet Worm found over 300 that had at least one of
several known security holes.

When we first obtained a connection to the ARPAnet, Dave Presotto
configured our gateway machine (named arpa) as an application-level
gateway.  For two years this machine was the sole official link
to the Internet for AT&T.  Until its disconnection in 1989, this VAX 750 handled
all the Internet mail traffic and other services for the company.
Arpa had Ethernet connections to both the inside and outside Internets, just
like a router.  It could also make and accept calls on our corporate Datakit
network.

Dave took a number of steps to make our gateway more secure.
He turned off IP forwarding in the kernel so packets could not
travel between the Internets.  He installed a kernel modification
that limited TCP connections from arpa to the inside network to smtp, uucp,
named, and hostname ports.  And he rejected the sendmail mailer as too
complicated and dangerous:  the Upas [cite upas] mailer was installed
in its place. We removed a number of non-essential daemons, including the
finger server.

To give insiders access to the Internet,  a gate service
was installed on arpa.  Insiders could call this service and
supply an Internet address.  The gate connected to a socket of a remote
Internet host and then copied bytes between the two connections.  It was
easy to provide atelnet, a version of telnet that used the gate service.
Aftp supplied FTP services:  it was the standard ftp modified so both the
command and data connections were initiated from the inside.  (The standard
ftp would have tried to make the data connection from arpa to the inside, a
connection prohibited by arpa's kernel.)

This configuration successfully resisted the Internet worm.  We ran neither
sendmail nor fingerd, the two programs exploited by the worm. [cite seeley] The
internal internet was spared the infection.  (Actually, there was a second,
unguarded IP link to the Outside.  We got lucky:  only a few machines
at the other end knew of the link, and their machines were shut down
before the worm could creep across.)

Had arpa been infected, the worm could have reached the inside
machines.  The initial smtp sendmail connection was permitted,
and the worm's second connection would have been initiated from the
inside target machine into arpa, the permitted direction.


The new gateway
--- --- -------
All of arpa's protection has, by design, left the internal AT&T machines
untested---a sort of crunchy shell around a soft, chewy center.
We run security scans on internal machines and bother system administrators
when holes are found.  Still, it would be nice to have a gateway that is
demonstrably secure to protect the internal machines.  For peace of mind,
the gateway design should not rely on vendors' code more than absolutely
necessary.  We would like the internal machines protected even if an invader
breaks into the gateway machine, becomes root, and creates and runs a new
kernel.

We had to replace arpa.  The VAX 750 ran with typical load averages of seven
to twelve jobs throughout the day.  When the load average hit about
fifteen, the old Datakit driver expired, wedging the Datakit ports and
requiring a reboot.

A new machine gave the opportunity for a clean start.
We could re-think the security arrangements to improve on arpa's shortcomings.

Our new gateway machine, named inet, is a MIPS M/120 running RISC/OS,
a System V implementation with Berkeley enhancements.  Various daemons and
critical programs have been obtained from other sources, checked,
and installed.

We store nothing vital or secret on inet, since we assume that it may be
defeated in unforeseen ways.  It does not run uucp---systems files and dialers
could fall into the wrong hands.  There are few system administration accounts,
and user accounts are discouraged.
Inet is not used for other tasks.
It is backed up regularly, and scanned for unauthorized changes and
common system administration mistakes.
Though we don't trust inet, we protect it as much as we can.

Inet has a single Ethernet port which is connected to a router
on JVNCnet, our external regional network.  It also has a connection to Datakit.
We have configured our Datakit controller to force all connections
from inet to a single internal machine, named r70.
R70 can redial, or splice connections to other internal machines.  R70
provides a limited set of services to inet for reaching internal machines.
The list of services are:
1. connection to an approved machine's smtp port,
2. connection to a login or trusted-login Datakit destination
   after passing a challenge-response test, and
3. connection to a logging service.

The key to the arrangement is a restricted channel from inet
to r70.  This private channel was easily constructed using stock features of
our research Datakit controller.  Other connection schemes could be implemented
using a simple multiplexed protocol over some back-to-back connection
between the machines, or a simple two-machine Ethernet would suffice.
If the last approach is used with TCP, the internal
machine must supply differing TCP services to its two Ethernet
interfaces.  (I am not sure this is possible with stock commercial TCP
software. It wouldn't be too hard to modify inetd to do this.)

These functions do not load the internal machine too much;
it could have other uses like uucp, mail, or even normal user jobs.
But the services it provides the external machine are the key
to security, and must be protected well.


Outbound services
-------- --------
It is quite easy to implement most outbound services to the Internet.
Inet has a small program, named proxy (a descendant of arpa's
gate), that makes calls to the Internet on behalf of an inside machine
and relays bytes between the inside Datakit connection and the outside
Internet TCP connection.  Proxy can also listen to a non-privileged socket
and report connections to an inside process.  Several outbound services
are implemented using proxy, and more are easy to create.
In all cases, it appears to the remote Internet hosts that our gateway
machine is making the calls.

%%%% picture of a proxy call

Inet may be reached over the Datakit.
But how do internal machines reach inet over the Ethernet?
R70 responds to two IP addresses: its own, and an internal IP address for
inet.  (Dave Presotto implemented this after a trivial change to the
Tenth Edition Research Unix connection server. [cite connection]
Calls to certain TCP ports on this internal IP address invoke dcon, a
program that simply relays the bytes between the TCP port
and Datakit connections on inet.

I have replaced the  old aftp and atelnet with ptelnet and pftp.  They work
in the same manner, but the new routines call a portable implementation of
ipcopen, a piece of the connection server.  Ipcopen hides the details of
a connection (TCP sockets or Datakit), simplifying the application program.
For example:
ptelnet tcp!toucan
connects to machine toucan on our internet, and
ptelnet proxy!ernie.berkeley.edu
connects to ernie.berkeley.edu on the external Internet.
proxy! is the default.
The ipcopen implementation is not flawless:
some socket features such as out-of-band data and the urgent pointer
are missing because they are not supported by Datakit.
Ptelnet was stripped down to avoid these features.

%%%% figure of a proxy

Pftp provides FTP access in a similar manner.  It is an updated
version of aftp from arpa.  The ipcopen routines allow it to work over Datakit.

The proxy software is available
by anonymous FTP from toucan.zoo.att.com.  The file is proxy.tar.Z.

% figure of pftp and ftp function

Outgoing mail is sent to inet via smtp over either Datakit or the
internal Internet.  It is stored and forwarded from there.  Upas
performs the mail gateway functions.


                    $ telnet research.att.com
                    Trying...
                    Connected to research.att.com.
                    Escape character is '^]'.


                    RISC/os (inet)

                    login: guard
                    RISC/os (UMIPS) 4.0 inet
                    Copyright 1986, MIPS Computer Systems
                    All Rights Reserved
                    Security Authentication check

                    login: ches
                    Enter response code for 90902479: 818b71fe

                    Destination please: coma
                    OKYou have mail.
                    coma=; date
                    Tue Nov 14 10:52:37 EST 1989
                    coma=;
                    Eof
                    Connection closed by foreign host.
                    $

                 *A connection session through the guard.*


Inbound services
------- --------
We provide incoming login and mail service.  For incoming file transfer,
inet provides an anonymous FTP service.

We do not trust our passwords to the Internet:  it is too easy to eavesdrop
or steal packets.  See [cite smb] for a discussion of these security problems.
Login service requires a hand-held authenticator (HHA).  These are
calculator-sized devices that contain DES encryption and a manually-loaded
64-bit key.  They cost about $60.

Inbound login service is provided through an authentication manager on
r70.  A session is shown in figure [ref  connect].
To connect, the following sequence occurs:
1.  The Internet caller uses telnet to connect to research.att.com
        inet via telnet.  The login name is tt guard.
2.  The tt guard login connects to the authentication manager on r70
        over the Datakit.  It spends the rest of the connection
        relaying bytes between the two connections.
3.  The authentication manager on r70 requests a login name.
4.  R70 sends a random challenge number, which the caller supplies.
5.  The user enters the challenge into his HHA.
6   The HHA encrypts the challenge using a pre-loaded DES key,
        and displays the response.
7.  The user types the response.  He has three tries to
        answer a challenge correctly, and is disconnected if he fails.
8.  The authorization manager prompts for a Datakit destination.
9.  When the user enters the destination, the manager sends a redial
    request to the Datakit controller with the given destination and
        a service of `dcon'.  For machines that trust r70, the `dcon'
        service bypasses further logins and avoids further passwords.
10. The redial request transfers the call, switching r70 out of
        the connection.  Connections for a TCP host are handed to rlogin.

Users may wish to trust the gate machine and so avoid typing any passwords
over the internet.  TCP callers can put r70-mhbb.research.att.com in their
.rhosts file.  For Datakit connections using the standard DKHOST software,
they can log in through the guard once using ptelnet, and then request the
destination area/exchange/host.authorize.t.
This will connect them to their own machine's authorization server,
which will prompt them for a login and password.  Obviously, this
should be done from a secure terminal, and not from out on the
Internet.
(Both of these practices are dangerous.  Do you really want to trust
r70?  It is probably safer than entering passwords on some alien
workstation out on the Internet.  We frown on user-level authentication in
general, preferring to have the system administrator make and support these
judgements.)

Each user requires a DES key, and keys have an expiration date.
The key file is stored on r70 in a file readable only by root.
This is unfortunate, and the file will probably move into an authentication
manager somewhere.

Inbound mail is delivered directly to inet.
Inet checks the destination.  If it is a trusted machine (i.e. its
smtp is trusted), a connection request is sent to r70.  If not,
the mail is relayed through an accessible internal machine.
R70 will permit connections only to trusted smtp implementations.
The list is short because most internal machines run sendmail.

% so why do we need inet?  Why not a Cisco with inet on the inside?

%%      The restricted list of known 112 smtps should be justified both from
%%    a security standpoint and a practicality one -- some smtps (i.e.,
%%    sendmail on sunos) have security bugs.  Thus, the techniques used
%%    to let logins through are not acceptable for mail.

% what about network file system connections into inet?  Another hole?

%%    You may want to have two public ftp directories, though I'm not certain
%%      exactly how to set things up this way without giving out inet logins.
%%    'pub' is mode 555 or 755 not owned by ftp; it's used for 'blessed'
%%    outgoing packages that we advertise for pickup.  'incoming' is mode 333
%%    or 733 -- i.e., not readable from the outside.  If you know the
%%    file name, you can pick it up, but you can't snoop for stuff.  This
%%    avoids things like you putting a file in there for me, but a cracker
%%    plants a horse before I get to it.  I've recommended a similar scheme
%%    to the Comp Centers; they like it so far.

%%    How does ftpd work without running as root?  On Berkeley systems
%%    at least, it can't function without being root when talking to
%%    a client that doesn't generate PORT commands.


Protecting INET
---------- ----
The preceding precautions might imply that we expect our gateway
to be compromised at some point.  In fact, we are taking great pains
to protect the machine, including the usual good system administration
steps needed to secure any Unix system [cite ritchie]: directory and file
permissions are checked, backups performed regularly, etc.

We have taken some steps to avoid denial-of-service attacks.
For example, the logs, the spool directory, and the publically-accessible
FTP directory are each on separate file systems.  If a stranger fills
the public FTP directory, there is still room for the logs.

Here are some other steps taken:

1.  All the important executable files are periodically
        checksummed and checked for changes.
2.  Most user accounts do not have passwords to be checked.  They
        obtain permission to login based on the source of the call.
3.  User accounts are discouraged.
4.  Non-essential network daemons have been removed:  we don't need
        to trust them.
5.  Inetd(8) handles all network connections.  Certain modifications
        allow telnetd, smtpd, and ftpd to run with reduced permissions:
        [cite ritchie] inetd handles the privileged stuff.
6.  There is extensive logging of network activity, including connection
        and login attempts.  Logs are stored forever on a WORM-based backup
        system.
7.  Since the network daemons are so important to the security of the machine,
        we obtained the latest BSD versions and examined, modified, and
        installed them.


Gateway alternatives
------- ------------
There are several much simpler alternatives for an Internet gateway.
The simplest is a router, which just lets the packets through.  Some
routers, like Cisco's, provide packet filtering that can block various
types of access to an institution.

We did not choose the router.  Though the filtering is quite good, it's
not clear whether a clever worm could get through the permitted ports.
Can we trust the router?
If telnet access is allowed from the outside, inside machines are exposed
to password-guessing attacks.  If telnet access is not allowed, an alternative
is needed anyway, requiring additional provisions.  The router does not
provide logging to detect invasion attempts.  And mail gating must be
provided by a machine somewhere:  it is unreasonable to expect each internal
machine to be configured to handle all the varieties of external mail
addressing.

Many Internet sites use a gateway machine like a Sun.  These machines forward
IP packets in both directions, and provide a mail gateway service.
The packet flow is still dangerous, though filtering is available.
Many internal machines may trust the gate machine, leaving them further
exposed if the gate machine is compromised.


Performance
-----------
The mail throughput of the new gateway has been gratifying,
though a VAX 750 is an easy act to follow. In many cases,
we have had replies to cross-country mail return in less than a minute.
It sometimes seems that the mail must have bounced.  Inet has little
else to do, and a MIPS M/120 is a fast machine.

Pftp transfers are fastest over Datakit, since they avoid the
dcon gateway in r70.  File transfers range from 17 to 44 Kb/sec.
TCP transfers through r70 run at 9 to 16 Kb/sec.  By comparison,
thinspace ftp on inet runs at about 60--90 Kb/sec.
Clearly, security has its costs.  But these are top speeds.  The limiting
factor is often the external net or host.  The throughput seems adequate, and
there have been no complaints.

% ftp> get /vmunix /dev/null
% 200 PORT command okay.
% 150 Opening data connection for /vmunix (192.20.225.2,2242) (707584 bytes).
% 226 Transfer complete.
% 707584 bytes received in 15.834 seconds (43.64 Kbytes/s)

%
%     19505 bytes from pilot.njin.net:
%          dk to inet:   1.1 sec 17.3 K/sec
%          TCP to inet:  1.4 sec 13.6 K/sec
%        dk to att-in: 13 sec   1.5 K/sec
%
%     17403 bytes from uunet.uu.net:
%          dk to inet:   .84 sec 20.2 K/sec
%          TCP to inet:  1.9 sec  8.9 K/sec
%        dk to att-in: 9.2 sec  1.8 K/sec
%
%


Conclusions
-----------
The new gateway achieves a useful balance of utility and
security.  Most internal users seem to be happy with pftp and
ptelnet.  Some have asked for talk, resolver service and other UDP-based
protocols.  These could be provided with non-proxy services
on inet accessible through Datakit.  Steve Bellovin has cooked up a
scheme to support X through the gateway.  The security implications are
frightening.

There are certainly limits to our security.  If r70 and inet are subverted,
the inside machines could be attacked.

Insiders can easily import trouble such as Trojan horses or programs
infected with viruses.  Our best defense is continued scanning of internal
machines for security holes in case such a program gets loose.

There is now a second AT&T internet gateway [cite horton].
Its configuration is based on this work.
These two front doors provide reasonable security to an isolated
internal internet.  But AT&T is a large company, so we keep a constant watch to
assure that no other links are made to the external Internet.  A locked front
door is useless if the back wall of the house is missing.

The incoming guarded telnet service is not perfect.  The remote telnet
may be insecure, and the TCP connection itself could be stolen after
login is complete.  Most internal AT&T machines do not accept r70's
judgement that the user is valid, and require their own login passwords.
These passwords travel over the Internet in the clear.

Our solution does have some drawbacks.
We rely on two machines and Datakit to keep things working.  This
yields three points of failure, while the simpler approaches have
(in some sense) only one point of failure.  The use of TCP-level gateways
does lower throughput.  Though most users seem to be content with the
pftp response, it would be nice to speed it up some.  The uptime of this
service is measured in months, and the mail transit time in seconds or minutes.

        This paper is not an invitation to come
    test the security of our gateway.
    It is management's policy to call the
    authorities when intruders are detected.


Acknowledgements
----------------
Many people have contributed to the support of
these gateways.  Steve Bellovin did most of the initial work to get arpa
talking to the ARPAnet and Datakit.
Dave Presotto has supplied much of the software and most
of the paranoia to provide a secure gateway.  Howard Trickey implemented
earlier versions of ptelnet and pftp.
Dennis Ritchie has kept a watchful eye and stepped in when things broke.
Steve Bellovin and others have provided numerous suggestions and warnings
on various networking and security topics.
Jim McKie ported many useful Research Unix [cite V10] functions and the
INCON Datakit driver to our MIPS computers, making life much easier for me.


1.  The box is completely reset.
    Enter a code digit and press "Enter":

                digit   &       hexadecimal encryption  &     "error"
                0       & yes                           &       yes
                1       & yes                           &       no
                4       & no                            &       yes
                5       & no                            &       no

        Hexadecimal encryption provides slightly higher security,
                but it is easy to mistake "6" and "b".  In decimal
                mode, the hexadecimal characters "a"--"c" and "d"--"f"
                are mapped to "2" and "3" respectively.  The guard software
                accepts either answer.  The error mode displays "error"
        if an invalid PIN is entered.  Five invalid entries will
                reset the box to .  If "error" is off, the SNK
                provides an invalid encryption.  We use mode 4.
2.  Enter the DES key.  The key consists of eight
    8-bit bytes typed in octal.  Press "Enter."
3.  Enters a 4 to 16-digit PIN, followed by "Enter."
4.  Re-enter the PIN, followed by "Enter."
5.  Enter the PIN followed by "Enter".
6.  Enter the challenge, followed by "Enter".
                The SNK displays the response.

Programming the Hand Held Authenticator
----------- --- ---- ---- -------------
We use the Securenet Key SNK-4.  It is available from

    Digital Pathways
    221 West Grand Avenue
    Montvale NJ  07645

It costs $60 in unit quantities.  Its major competitor is the
SecureId card.  The latter uses a time-based algorithm to generate
the key and requires substantial and expensive software in the
host.  The SNK-4 needs a small program that uses the standard
encrypt function.

We program the SNK-4s by hand, though a PC-based system is
available as well.  Figure [ref programming] details the programming
steps.

The SNK shuts off automatically after 30 seconds.  Press
"On" to restart.

We have found that the battery runs down in the SNK if the
"On" button is pressed continuously, say, in luggage.  The
bumps around the "On" switch don't protect the switch well
enough.  We suggest storing the box in the original packing
material.


Bibliography
------------
upas
    David Presotto.
        Upas - a simpler approach to network mail.
        USENIX Summer Conference Proceedings, pps.533-538, June 1985.
seeley
    Donn Seeley.
        A Tour of the Worm.
    USENIX Winter Conference Proceedings, Jan. 1989.
connection
    David Presotto and Dennis Ritchie.
        Interprocess Communication in the Ninth Edition UNIX System.
    Unix Programmer's Manual, Tenth Edition.
    A. G. Hume and M. D. McIlroy, Editors.
        AT&T Bell Laboratories, Murray Hill, NJ. 1990.
smb
    Bellovin, S.M.
        Security Problems in the TCP/IP Protocol Suite.
    Computer Communications Review, Vol. 9, No. 2; April, 1989,
        pps.32-48.
ritchie
    Ritchie, Dennis M.
        On the Security of UNIX.
    Unix Programmer's Manual, Tenth Edition.
    A. G. Hume and M. D. McIlroy, Editors.
        AT&T Bell Laboratories, Murray Hill, NJ. 1990.
V10
    Unix Programmer's Manual, Tenth Edition, Volumes One and Two.
    A. G. Hume and M. D. McIlroy, Editors.
        AT&T Bell Laboratories, Murray Hill, NJ. 1990.
horton
    Horton, Mark R.
        Charter for an Electronic Communication Gateway Service - Issue 1.
        %MRH CB 45264 4276 1E-271
    45264-881003.01IM.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                            NIA074 / File 5

            Notes on Centigram Voice Mail system Consoles

Proper entry procedure, possible design flaw and serious security
bug:

     Due to, I assume, more efficient task-handling and the
desire for a more 'Unix-like' environment, the developers at
Centigram needed for certain key functions to be available at all
times.  For instance, the ^Z key acts as the 'escape' key (these
can be remapped, if desired).  When necessary for some
applications to use an 'escape' procedure, pressing this key can,
in at leas cases, cause a drop to shell, or /cmds/qnxsh
(possibly /cmds/sh, as well, but I'm used to seeing qnxsh).  If
this escape procedure were invoked during, say, /cmds/login, the
resulting drop to shell would by-pass the 'Enter Passcode:'
message.  And it does.

     After calling the Centigram, normal procedure is to hit ^Z
to activate the terminal, followed by the entry of the remote or
console passcodes, and then proceeding with normal console
activities.  However, if ^Z is continually depressed during the
login sequence, the login program will abort and run /cmds/qnxsh.
The behavior may be somewhat erratic by the repeat use of the
escape key, but when the $ prompt appears, usually, it doesn't
deliberately go away without an 'exit' command or a ^D.
Typically, a login pattern can develop to accommodate the erratic
behavior something along the lines of: continuously depress ^Z
until $ prompt appears, hit return, possibly get 'Enter Passcode:'
message, hit return, and $ prompt appears again, set proper tty
setting, and change directory appropriately, and continue with
normal console functions.

Initial STTY Setting:

     I've had problems with my terminal settings not being set
properly during the above entry procedure.  I can correct this by
using the "stty +echo +edit" command, and, for my terminal, all
is restored.  The correct values for STTY options and keys appear
to be:

Options: +echo +edit +etab +ers +edel +oflow +mapcr +hangup
 break=03h     esc=1Ah     rub=7Fh     can=18h     eot=04h      up=15h

 down=
0Ah    left=08h     ins=0Eh     del=0Bh

     The keymap, of course, can be modified as desired, but the
options, especially +edit, appear to be necessary.

[A somewhat detailed description of the options could follow, or
maybe just a list and a brief review of the ones I care to
comment on]

Disks and directories:

     The drives and directories are set up in a remotely MessDos
fashion.  The output of a 'pwd' command looks similar to '4:/'.
'4;' represents the drive number, and '/' is the start of the
directory structure, '4:/' being the root directory for drive 4,
'3:/tmp' being the /tmp directory on drive 3, etc.

     The two most important directories are 1:/cmds and 4:/cmds,
which contain, for the most part, the program files for all of
the performable commands on the system, excluding the commands
written into the shell.  The directory 1:/cmds should look
similar to:

$ ls
 backup        drel          ls            rm            talk
 chattr        eo            mkdir         rmdir         tcap
 choose        fdformat      mount         runfloppy     timer
 clrhouse      files         p             search        tsk
 cp            frel          pack          sh            unpack
 date          get_boolean   patch         slay          ws
 ddump         led           pwd           sleep         zap
 diff          led.init      qnxsh         spatch
 dinit         login         query         stty

     This is a display of many useful commands.  chattr changes
the read/write file attributes, cp is copy, ddump dumps disk
sectors in hex & ascii, led is the line editor, p is the file
print utility, and a variety of other things that you can
experiment with at your own leisure.  DO NOT USE THE TALK
COMMAND.  At least, be careful if you do.  If you try to
communicate with your own terminal, it locks communication with
the shell, and upon hangup, for some reason, causes (well, in one
instance) a major system error and system-wide reboot, which,
quite frankly, made me say 'Oops. I'm not doing that again'
when I called to check on the actual voice mailboxes, and the
phone line just sat there, dead as old wood; and I was quite
relieved that it came back up after a few minutes.

     The other directory, 4:/cmds, is filled with more specific
commands pertaining to functions within the voice mail system
itself.  These programs are actually run from within other
programs, to produce an easy-to-understand menu system.
Normally, this menu system is immediately run after the entry
of the remote or console passcode, but it would not be run when
using the aforementioned security bug.  It can be run from the
shell simply by typing the name of the program, 'console'.

Mounting and Initializing Drives:

     The MOUNT command produces results similar to this when run
without arguments:

$ mount
Drive 1:    Hard,  360k, offset =  256k, partition= Qnx
Drive 2:  Floppy,  360k, p=1Drive 3: RamDisk,   96k, partition= Qnx
Drive 4:    Hard,  6.1M, offset =  616k, partition= Qnx
$tty0  = $con,     Serial at 03F8
$tty1  = $term1 ,     Serial at 02F8
$tty2  = $term2 ,     Serial at 0420
$tty3  = $mdm   ,     Serial at 0428

     The Hard and Floppy drives are fairly self-explanatory,
although I can't explain why they appear to be so small, nor do
I know where the voice recordings go, or if this list contain all
the space required for voice storage.

     The Ramdisk, however, is a bit more interesting to me.  The
mount command used for the above-mentioned disk 3 was:

$ mount ramdisk 3 s=96k -v

      Although I'm not sure what the -v qualifier does, the rest
is fairly straightforward.  I assume that the size of the drive
can be greater than 96k, although I haven't yet played with it to
see how far it can go.  To initialize the drive, the following
command was used:

$ dinit 3

     Quite simple, really.   Now the drive is ready for use, so
one can 'mkdir 3:/tmp' or such and route files there as desired,
or use it for whatever purpose.  If something is accidentally
redirected to the console with >$cons, you can use the line
editor 'led' to create a temporary file and then use the print
utility 'p' to clear the console's screen by using "p filename
>$cons", where filename contains a clear screen of 25 lines, or
an ANSI bomb (if appropriate), or a full-screen DobbsHead or
whatever you like.

EVMON and password collecting:

     The evmon utility is responsible for informing the system
manager about the activity currently taking place within the
voice mail system.  Run alone, evmon produces output similar to:

$ evmon
Type Ctrl-C to terminate.
ln  26 tt 3
ln  26 line break
ln  26 onhook
ln  28 ringing
ln  28 tt 8
ln  28 tt 7
ln  28 tt 6
ln  28 tt 2
ln  28 offhook
ln  28 tt *
ln  28 tt 2
ln  28 tt 0
ln  28 tt 3
ln  28 tt 0
ln  28 line break
ln  28 onhook
[...]

And so forth.  This identifies a certain phone line, such as line
28, and a certain action taking place on the line, such as the
line ringing, going on or offhook, etc.  The 'tt' stands (I
assume) for touch tone, and it is, of course, the tone currently
played on the line; which means that touchtone entry of passcodes
can be recorded and filed at will.  In the above example, the
passcode for Mailbox 8762 is 2030 (the * key, along with the 0
key, can acts as the 'user entering mailbox' key; it can,
however, also be the abort key during passcode entry, and other
things as well).  Now the user, of course, doesn't (usually) dial
8762 to enter his mailbox, he simply dials the mailbox number and
then * plus his passcode; the reason for this is the type of
signalling coming from the switch to this particular business
line was set-up for four digit touch tone ID to route the line to
the appropriate called number.  This is not the only method of
signalling, however, as I've seen other businesses that use three
digit pulse signalling, for example, and there are others as
well.  Each may have it's own eccentricities, but I would imagine
that the line ID would be displayed with EVMON in most cases.

     Now, let's say we're online, and we want to play around, and
we want to collect passcodes.  We've set up our Ramdisk to normal
size and we are ready to run evmon.  We could run it, sit at our
terminal, and then record the output, but it's such a time
consuming task (this is 'real-time', after all) that sitting and
waiting be nearly pointless.  So, we use the handy features of
run-in-background and file-redirection.  (See, I told you we were
getting 'Unix-like'.)

$ evmon > 3:/tmp/output &
Type Ctrl-C to terminate.
5e1e
$ ...

     5e1e is the task ID (TID) of the new evmon process.  Now we
can go off and perform whatever lists we want, or just play in
the directories, or route DobbsHeads or whatever.  When we decide
to end for the day, we simply stop EVMON, nab the file, remove
it, and if necessary, dismount the ramdisk.

$ kill 5e1e
$ p 3:/tmp/output
[ EVMON output would normally appear; if, however, ]
[ there is none, the file would be deleted during  ]
[ the kill with an error message resulting         ]
$ rm 3:/tmp/output
$ rmdir 3:/tmp
$ mount ramdisk 3

     and now we can ^D or exit out of the shell and say good-bye.

     The good thing about this EVMON procedure is that you don't
need to be online while it runs.  You could start a task sometime
at night and then wait until the next day before you kill the
process and check your results.  This usually produces large log
files anywhere from 40K to 200K, depending upon the amount of
system usage (these figures are rough estimates).  If, however,
you start the EVMON task and leave it running, then the
administrator will not be able to start a new EVMON session until
the old task is killed.  While this probably shouldn't be a
problem over the weekends, during business hours it may become a
little risky.

     Remember though, that the risk might be worth it, especially
if the administrator decides to check his mailbox; you'd then
have his passcode, and possibly, remote telephone access to
system administrator functions via touch-tone on the mailbox
system.

Task management:

     As we have just noted, any task like EVMON can be run in the
background by appending the command line with a &, the standard
unix 'run-in-background' character.  A Task ID will echo back in
hexadecimal, quite comparable to the unix Process ID.  The
program responsible for task management is called 'tsk' and
should be in 1:/cmds/tsk.  Output from running tsk alone should
look something like:

$ tsk
Tty Program         Tid  State Blk  Pri   Flags     Grp Mem Dad  Bro  Son
  0 task            0001 READY ----  1 ---IPLA----- 255 255 ---- ---- ----
  0 fsys            0002 RECV  0000  3 ---IPLA----- 255 255 ---- ---- ----
  0 dev             0003 RECV  0000  2 ---IPLA----- 255 255 ---- ---- ----
  0 idle            0004 READY ---- 15 ----PLA----- 255 255 ---- ---- 0508
  0 /cmds/timer     0607 RECV  0000  2 -S--P-AC---- 255 255 ---- ---- ----
  0 /cmds/err_log   0509 RECV  0000  5 -S--P--C---- 255 255 0A0A ---- ----
  0 /cmds/ovrseer   0A0A REPLY 0607  5 -S--P--C---- 255 255 ---- ---- 030C
  0 /cmds/recorder  010B REPLY 0509  5 -S--P--C---- 255 255 0A0A 0509 ----
  0 /cmds/master    030C REPLY 0607  5 -S--P--C---- 255 255 0A0A 010B 011C
              [ ... a wide assortment of programs ... ]
  0 /cmds/vmemo     011C REPLY 0110 13 -S-----C---- 255 255 030C 011B ----
  3 /cmds/comm      0508 RECV  5622  8 ----P-A----- 255 255 0004 ---- 5622
  3 /cmds/tsk       051D REPLY 0001  8 ------------ 255 255 301E ---- ----
  3 /cmds/qnxsh     301E REPLY 0001 14 ---------E-- 255 255 5622 ---- 051D
  3 /cmds/login     5622 REPLY 0003  8 -------C---- 255 255 0508 ---- 301E


Although I'm not quite sure at some of the specifics
displayed in this output, the important parts are obvious.  The
first column is the tty number which corresponds to the $tty list
in 'mount' (meaning that the modem I've just called is $tty3, and
I am simultaneously running four tasks from that line); the
second column is the program name (without the drive
specification); the third column is the task ID; the middle
columns are unknown to me; and the last three represent the ties
and relations to other tasks (Parent task ID, another task ID
created from the same parent, and task ID of any program called).

     Knowing this, it's easy to follow the tasks we've created
since login.  Initially, task 0508, /cmds/comm, was run, which
presumably contains the requisite 'what should I do know that my
user has pressed a key?' functions, which called /cmds/login to
log the user in.  Login was interrupted with ^Z and one of the
shells, qnxsh, was called to handle input from the user.
Finally, the typing of 'tsk' requires that the /cmds/tsk program
be given a task ID, and the output of the program is simply
confirming that it exists.

     As mentioned, to kill a task from the shell, simply type
'kill [task-id]' where [task-id] is the four digit hexadecimal
number.

     There are other functions of the tsk program, as well.  The
help screen lists:

$ tsk ?
use: tsk [f={cmoprst}] [p=program] [t=tty] [u=userid]
     tsk code [p=program]
     tsk info
     tsk mem t=tid
     tsk names
     tsk size [p=program] [t=tty] [u=userid]
     tsk ports
     tsk
tsk
     tsk tree [+tid] [+all] [-net]
     tsk users [p=program] [t=tty] [u=userid]
     tsk vcs
     tsk who tid ...
options: +qnx -header +physical [n=]node s=sort_field

     I haven't seen all the information available from this, yet,
as the plain 'tsk' tells me everything I need to know; however,
you may want to play around, there's no telling what secrets are
hidden...

$ tsk tsk
Tsk tsk? Have I been a bad computer?

     See what I mean?

ddump:

     The ddump utility is used to display the contents on a
specified blocks of the disk.  It's quite simple to use.

$ ddump ?
use: ddump drive block_number [-v]

     Again, I'm not quite sure what the -v switch does, but the
instructions are very straightforward.  Normal output looks
similar to:

$ ddump 3 3
Place diskette in drive 3 and hit <CR>     <-- this message is always
                                               displayed by ddump.
Block 00000003  Status: 00
000:  00 00 00 00 00 00 00 00 94 00 00 00 00 00 00 00 ................
010:  01 00 01 00 40 02 00 00 00 02 00 00 00 00 00 00 ....@...........
020:  00 01 00 FF FF 00 00 97 37 29 17 00 01 01 01 30 ........7).....0
030:  C4 17 8E 62 69 74 6D 61 70 00 00 00 00 00 00 00 ...bitmap.......
040:  00 00 00 00 C0 00 00 00 00 00 00 00 00 00 00 00 ................
050:  00 00 00 FF FF 00 00 A5 37 29 17 00 01 01 17 30 ........7).....0
060:  C4 25 8E 6C 6C 6C 00 00 00 00 00 00 00 00 00 00 .%.lll..........
070:  00 00 00 00 50 0E 00 00 00 0E 00 00 00 00 00 00 ....P...........
080:  00 01 00 FF FF 7E 05 A8 38 29 17 00 01 01 17 30 .....~..8).....0
090:  C4 28 8F 61 62 63 00 00 00 00 00 00 00 00 00 00 .(.abc..........
0A0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0B0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[...etc...]

     As you can probably notice, what we have here is the
directory track for the ramdisk.  It lists three files, even
though the file abc no longer exists.  The actual bytes have yet
to be decoded, but, as far as the ramdisk goes, I suspect that
they'll be memory related, and not physical block related; that
is, I suspect that some of the numbers given above correspond to
the memory address of the file, and not to the actual disk-block.
So, at least for the ramdisk, finding specific files may be
difficult.  However, if you only have one file one the ramdisk
besides 'bitmap' (which appears to be mandatory across all the
disks), then the next file you create should reside on track 4
and continue working it's way up.  Therefore, if you have evmon
running and redirected to a file on the ramdisk, in order to
check the contents, it's not necessary to kill the process, and
restart evmon, etc.  Simply 'ddump 3 4', and you could get either
useless information (all the bytes are 00 or FF), or you could
get something like:

$ ddump 3 4
Place diskette in drive 3 and hit <CR>

Block 00000004  Status: 00
000:  00 00 00 00 00 00 00 00 00 00 00 00 09 00 00 00 ................
010:  6C 6E 20 20 32 36 20 74 74 20 33 1E 6C 6E 20 20 ln  26 tt 3.ln
020:  32 36 20 6C 69 6E 65 20 62 72 65 61 6B 1E 6C 6E 26 line break.ln
030:  20 20 32 36 20 6F 6E 68 6F 6F 6B 1E 6C 6E 20 20   26 onhook.ln
040:  32 38 20 72 69 6E 67 69 6E 67 1E 6C 6E 20 20 32 28 ringing.ln  2
050:  38 20 74 74 20 38 1E 6C 6E 20 20 32 38 20 74 74 8 tt 8.ln  28 tt
060:  20 37 1E 6C 6E 20 20 32 38 20 74 74 20 36 1E 6C  7.ln  28 tt 6.l
070:  6E 20 20 32 38 20 74 74 20 32 1E 6C 6E 20 20 32 n  28 tt 2.ln  2
080:  38 20 6F 66 66 68 6F 6F 6B 1E 6C 6E 20 20 32 38 8 offhook.ln  28
090:  20 74 74 20 2A 1E 6C 6E 20 20 32 38 20 74 74 20  tt *.ln  28 tt

     ... and so forth, thus making sure that the file does have
some content.  Depending upon the length of that content, you
could then choose to either keep the file running, or restart
evmon and buffer the previous output.

led:

     The program 'led' is Centigram's answer to a standard text
editor.  It is equivalent to 'ed' in unix or 'edlin' in MSDOS,
but it does have it's minor differences.  led is used to create
text files, edit, existing log files, or edit executable shell
scripts.  By typing 'led [filename]', you will enter the led
editor, and if a filename is specified, and it exists, the file
will be loaded and the editor set to line 1.  If there is no
filename on the command line, or the file does not exist, of the
file is busy, then led begins editing a null file, an empty
buffer, without the corresponding filename.  (Commands can also
be specified to be used in led after the filename is entered.  If
needed, you can experiment with this.)

 Notable commands from within led:

   i             insert
   a             append
   w [filename]  write to disk; if no file is named, attempt to
                 write to current file; if there is no current
                 file, do not write.
   d             delete current line
   a number      goto line numbered
   q             quit (if not saved, inform user to use 'qq')
   qq            Really quit

     When inserting or appending, led will prompt you with a '.'
period.  To end you entry, simply enter one period alone on a
line, and you will then return to command mode.  When displaying
the current entry, led will prefix
all new, updated lines, with the 'i' character.

     The key sequence to enter a Dobbshead into a file and
redirect it to the console, then, would be:

$ led 3:/dobbshead3:/dobbshead : unable to match file
i               ___
           .  /   \
           . | o o |
           . |  Y  |
           U=====  |
              \___/
           FUCK YOU!
q
?4 buffer has been modified, use qq to quit without saving
w 3:/dobbshead
7 [the number of lines in the file]
q
$ p 3:/dobbshead > $cons
$ rm 3:/dobbshead

     Ok, so it's not quite the Dobbshead.  Fuck you.

The console utility:

     The program that acts as the menu driver for the Voice Mail
System Administration, the program that is normally run upon
correct passcode entry, is /cmds/console.  This program will
simply produce a menu with a variety of sub-menu's that allow
the administrator to perform a wide assortment of tasks.  Since
this is mostly self-explanatory, I'll let you find out about
these functions for youself; I will, however, add just a few
comments about the console utility.  The first menu received
should look like this:

(c) All Software Copyright 1983, 1989 Centigram Corporation
All Rights Reserved.

         MAIN MENU

(R) Mailbox maintenance
(R) Report generation
(S) System maintenance
(X) Exit

Enter letter in () to execute command.
When you need help later, type ?.

COMMAND (M/R/S/X):

     The mailbox maintenance option is used when you want to
find specific information concerning mailboxes on the system.
For instance, to get a listing of all the mailboxes currently
being used on the system:

COMMAND (M/R/S/X): m

    MAILBOX MAINTENANCE

(B) Mailbox block inquiry
(C) Create new mailboxes
(D) Delete mailboxes
(E) Mailbox dump
(I) Inquire about mailboxes
(L) List maintenance
(M) Modify mailboxes
(P) Set passcode/tutorial
(R) Rotational mailboxes
(S) Search for mailboxes
(X) Exit

If you need help later, type ?.

COMMAND (B/C/D/E/I/L/M/P/R/S/X): i
Report destination (c/s1/s2) [c]:

Mailbox to display: 0000-9999

                              >>> BOBTEL <<<
                             Mailbox Data Inquiry
                            Tue Mar 31, 1992  3:07 am

Box        Msgs Unp Urg Rec   Mins FCOS LCOS GCOS NCOS MWI           Passwd
8001         1   1   0   0     0.0 5    5    1    1   None           Y
8002         0   0   0   0     0.0 5    5    1    1   None           Y (t)
8003         0   0   0   0     0.0 12   12   1    1   None
                     0   0     0.0 12   12   1    1   None           Y
8006            6   6   0   0     0.7 12   12   1    1   None           N
8008         0   0   0   0     0.0 5    5    1    1   None           Y
8013           0   0   0   0     0.0 12   12   1    1   None           1234
8014         0   0   0   0     0.0 5    5    1    1   None           Y
8016         0   0   0   0     0.0 12   12   1    1   None           Y
[ ... etc ... ]

     This simply lists every box along with the relevant
information concerning are the
Total number of messages, number of unplayed messages, number of
urgent messages, and number of received messages currently being
stored on the drive for the mailbox; Mins is the numbers of
minutes currently being used by those messages; F, L, G, and
NCOS are various classes of service for the mailboxes; MWI is
the message waiting indicator, or service light; and Passwd is
simply a Yes/No condition informing the administrator whether
the mailbox currently has a password.  The'(t)' the password
field means the box is currently in tutorial mode, and the '1234'
that replaces the Y/N condition, I assume, means the box is set
to initial tutorial mode with simple passcode 1234 -- in other
words the box is available to be used by a new subscriber.
Mailboxes with FCOS of 1 should be looked for, these represent
administration or service mailboxes, although they are not
necessarily capable of performing system administration
functions.

     The System maintenance option from the main menu is very
useful in that, if you don't have access to the qnxsh, you can
still run a number of tasks or print out any file you wish from
within the menu system.  The System Mainenance menu looks like:

         SYSTEM MAINTENANCE

(A) Automatic Wakeup
(B) Automated Receptionist Extensions
(D) Display modem passcode
(E) Enable modem/serial port
(F) Floppy backup
(G) Resynchronize HIS PMS room status
(H) Hard Disk Utilities
(L) Lights test
(M) Manual message purge
(N) System name
(P) Passcode
(R) Reconfiguration
(S) System shutdown
(T) Time and date
(U) Utility menu
(V) Call Detail Recorder
(W) Network menu
(X) Exit

Enter letter in () to execute command.
When you need help later, type ?.

COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X):

     If you don't have access to the 'p' command, you can still
display any specific file on the drive that you wish to see.
Choose 'v', the Call Detail Recorder option, from above, and you
will get this menu:

COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X): v
Warning: cdr is not running.

CALL DETAIL RECORDER MENU

(C) Configure CDR
(R) Run CDR
(T) Terminate CDR
(E) Run EVMON
(F) Terminate EVMON
(S) Show CDR log file
(D) Delete CDR log file
(X) Exit

If you need help later, type ?.

COMMAND (C/R/T/E/F/S/D/X):

     From here, you can use (C) Configure CDR to set the log
file to any name that you want, and use (S) to print that file
to your terminal.

COMMAND (C/R/T/E/F/S/D/X): c

Answer the following question to configure call detail recorder
[ simply hit return until the last 'filename' question come up ]
VoiceMemo line numbers enabled:
HOST 1 lines:
 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
VoiceMemo line numbers:

EVMON: HOST 1 lines to monitor:
 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
EVMON:VoiceMemo line numbers:
Message levels are:
     1:  Detailed VoiceMemo
     2:  VoiceMemo
     3:  Pager
     4:  Receptionist
     5:  EVMON
     6:  Automatic WakeUp
     7:  Open Account Administrator
     8:  DTMF to PBX
     9:  Message Waiting Lamp
    10:  SL-1 integration
    11:  Centrex Integration
Message levels enabled:
 2  3  7  9
Message levels:
cdr enable = [N]
Enter filename to save log data = [/logfile] /config/remote.cmds

Returning from the CDR configuration.

CALL DETAIL RECORDER MENU

(C) Configure CDR
(R) Run CDR
(T) Terminate CDR
(E) Run EVMON
(F) Terminate EVMON
(S) Show CDR log file
(D) Delete CDR log file
(X) Exit

If you need help later, type ?.

COMMAND (C/R/T/E/F/S/D/X): s
ad
cd
copy
date
dskchk
evmon
files
ls
mount
p
pwd
query
task
tcap
what

     Don't forget to return the filename back to it's original
name, as shown in the [] field, after you have finished.

     If you don't have access to the shell, you can also run
EVMON, from the CDR menu, using option E.  It will simply start
the evmon process displaying to your terminal, interruptable by
the break character, ^C.  This, unfortunately, cannot be
redirected or run in the background as tasks running from the
shell can.  If, however, you have some time to kill you may want
to play with it.

     Also from the System Maintenance menu, you can perform a
number of shell tasks without direct access to the shell.  Option
(U), Utilities Menu, has an option called Task.  This will allow
you limited shell access, possibly with redirection and '&' back-
grounding.

COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X): U

         UTILITY MENU

(B) Reboot
(H) History
(T) Task
(X) Exit

Enter letter in () to execute command.
When you need help later, type ?.

COMMAND (B/H/T/X): t

Choose the following commands:
             ad             cd           copy           date
         dskchk          evmon          files             ls
          mount              p            pwd          query
           task           tcap           what

Enter a command name or 'X' to exit: pwd
1:/

Choose the following commands:
             ad             cd           copy           date
         dskchk          evmon          files      ls
         mount              p            pwd          query
          task           tcap           what

Enter a command name or 'X' to exit: evmon
Type Ctrl-C to terminate.
ln  29 ringing
ln  29 tt 8
ln  29 tt 0
ln  29 tt 8
ln  29 tt 6
ln  29 offhook
ln  29 record ended
[ ... etc ... ]

A look at 'ad':

     The program 'ad' is called to dump information on a variety
of things, the most useful being mailboxes.  Dumps of specific
information about a mailbox can be done either in Mailbox format,
or Raw Dump format.  Mailbox format looks like:

$ ad
Type #: 0
Mailbox #: 8486
(M)ailbox, (D)ump ? m

MAILBOX: 8486

Login status:
    Bad logs     = 3          Last log     = 03/26/92 12:19 pmVersion = 0

Configuration:
    Name #       = 207314     Greeting     = 207309     Greeting2    = 0
    Passcode     = XXXXXXXXXX Tutorial     = N          Extension    = 8486
    Ext index    = 0          Attendant    =            Attend index = 0
       Code      =            ID           = BOBTECHM   Night_treat  = M          Fcos         = 12    Lcos         = 12         Gcos         = 1          Ncos         = 1    Rot index    = 0          Rot period   = 0    Rot start    = --    wkup defined = N          wkup freq    = 0          wkup_intvl   = 0    wkup index   = 0          wkup number  =Contents:    Motd_seq     = 8          Motd_played  = N          User_msgs    = 0    Caller_msgs  = 4          Sent_cpx_msgs= 0          Sent_
         fdx_msgs= 0
    Sent_urg_msgs= 0          Tas_msgs     = 0          Pages        = 0
    Receipt      = 0          Sent_to_node = 0          Urg_to_node  = 0
    Net_urg_mlen = 0          Net_msgs_rcv = 0          Net_urg_rcv  = 0
    Net_sent_node= 0          Net_send_nurg= 0          Net_send_rcp = 0
    Greet_count  = 9          Successlogins= 1          Recpt_calls  = 0
    Recpt_complt = 0          Recpt_busy   = 0          Recpt_rna    = 0
    Recpt_msgs   = 0          Recpt_attend = 0          User_connect = 20
    Clr_connect  = 22         Callp_connect= 0          Disk_use     = 498
    Net_sent_mlen= 0          Net_rcvd_mlen= 0          Net_rcvd_urg = 0
    Net_node_mlen= 0          Net_recip_mlen=0          Net_node_urg = 0
    Text_msg_cnt = 0


Message Queues:
    TYPE           COUNT TOTAL HEAD TAIL  TYPE           COUNT TOTAL HEAD TAIL
    Free             71   ---   58   55   Unplayed          0   ---   -1   -1
    Played            2   0.5   56   57   Urgent            0   ---   -1   -1
    Receipts          0   ---   -1   -1   Undelivered       0   ---   -1   -1
    Future delivery   0   ---   -1   -1   Call placement    0   ---   -1   -1

Messages: 2
 #  msg #   DATE    TIME   LENGTH      SENDER     PORT   FLAGS  MSG     SIBL
                           (MINS)                               NXT PRV NXT PRV
Played Queue
56 207126 03/26/92 12:17 pm    0.5 000000000000000  27 ------P-  57  -1  -1  -1

57 207147 03/26/92 12:19 pm    0.1 000000000000000  29 ------P-  -1  56  -1  -1

     The Ramp format looks like:
$ ad
Type #: 0
Mailbox #: 8487
(M)ailbox, (D)ump ? d

HEX: 8487
000: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 34 38 |..............48|
030: 37 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |7...............|
040: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
050: 00 00 00 00 00 00 00 00 - 00 00 42 49 4f 54 45 43 |..........BOBTEC|
060: 48 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |H...............|
070: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
080: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 37 32 33 |.............723|
090: 36 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |6...............|
0a0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
0b0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
0c0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
[mostly deleted -- the list continues to hex fff.]

     One of the unfortunate aspects is that the password is not
displayed in the Mailbox format (Awwww!).   I can tell you now,
though, that it also isn't displayed anywhere in the Raw Dump
format.  The program 'asetpass' was used to change the password
of a test mailbox, and both full dumps were downloaded and
compared; they matched exactly.  So, it looks like the passcodes
are probably stored somewhere else, and the dump simply contains
a link to the appropriate offset; which meansthe only way, so
far, to get passcodes for mailboxes is to capture them in EVMON.

Intricacies of the login program:

     The console login program is 1:/cmds/login.  Although I
can't even recognize any valid 8080 series assembly in the
program (and I'm told the Centigram boxes run on the 8080
family), I did manage to find a few interesting tidbits inside of
it.  Firstly, the console and remote passwords seems to be stored
in the file /config/rates; unfortunately, it's encrypted and I'm
not going to try to break the scheme.  /config/rates looks like
this:

$ p /config/rates
\CE\FFC~C~\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00
\00\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00

     Accepting the \CE as some sort of control byte, this file is
divided up into about eight empty sections of five bytes a piece,
mostly null, indicating that, possibly, there are a number of
acceptable passcode combinations, or a number of different
functions with different passcodes.  In this instance, only one
passcode appears to be selected.  I am still unsure, however,
whether this is actually a password file, or a file that would
acts as a pointer to another space on the disk which contains the
actual password.  I would assume, for this login program, that it
is actually an encrypted password.

     Another very interesting thing sleeping within the confines
of the login program is the inconspicuous string 'QNX'.  It sits
in the code between two 'Enter Passcode:' prompts, separated by
\00's.   I believe this to be a system-wide backdoor placed into
the login program by Centigram, Corp.  Such a thing does exist;
whenever Centigram wants to get into a certain mailbox system to
perform maintenance or solve a problem, they can.  They may,
however, require the Serial number of the machine or of the Hard
Drive, in order to get this access.  (This serial number would be
provided by the company requiring service.)

     When logging in with QNX, a very strange thing happens.

(^Z)
Enter Passcode: (QNX^M)  Enter Passcode:

     A second passcode prompt appears, a prompt in which the
'QNX' passcode produces an Invalid Passcode message.  I believe
that when Centigram logs in from remote, they use this procedure,
along with either a predetermined passcode, or a passcode
determined based on a serial number, to access the system.  I
have not ever seen this procedure actually done, but it is the
best speculation that I can give.

     I should also make note of a somewhat less important point.
Should the console have no passcodes assigned, a simple ^Z for
terminal activation will start the /cmds/console program, and
log the user directly in without prompting for a passcode.  The
odds on finding a Centigram like this, nowadays, is probably as
remote as being struck by lightning, but personally, I can recall
a time a number of years back when a Florida company hadn't yet
passcode protected a Centigram.  It was very fun to have such a
large number of people communicating back and forth in normal
voice; it was even more fun to hop on conferences with a number
of people and record the stupidity of the average Bell operator.

Special Keys or Strings:

     There are a number of special characters or strings that are
important to either the shell or the program being executed.
Some of these are:

?     after the program name, gives help list for that program.
&     runs a task in the background
:     sets the comment field (for text within shell scripts)
;     command delimiter within the shell
>     redirects output of a task to a file
<     (theoretically) routes input from a file
$cons the 'filename' of the console (redirectable)
$tty# the 'filename' of tty number '#'
$mdm  the 'filename' of the modem line
#$    ? produces a value like '1920', '321d'
        probably the TID of the current process
##    ? produces a value like 'ffff'
#%    ? produces a value like '0020', '001d'
#&    ? produces a value like '0000'
#?    ? produces a value like '0000'
#*    a null argument
#g    ? produces a value like '00ff'
#i    directly followed by a number, produces '0000'
      not followed, produces the error 'non-existent integer
      variable' probably used in conjunction with environment
      variables
#k    accepts a line from current input (stdin) to be
      substituted on the command line
#m    ? '00ff'
#n    ? '0000'
#p    ? '0042'
#s    produces the error 'non-existent string variable'
      probably used in conjunction with environment variables
#t    ? '0003'
#u    ? some string similar to 'system'
#D    ? '0018'
#M    ? '0004'
#Y    ? '005c'

"Notes on Centigram Voice Mail system Consoles" was written
anonymously.  There are no group affiliations tied to this file.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                           NIA074 / File 05

                      How to steal Information

                            The Butler...



Now that we have entered the "Information Age" we must realize that
information is an asset worth protecting.  The problem is that what
some people consider trash others view as gold.  That is why on any
given day you can find mounds of valuable information in most
companies trashcans, employees desks, and on floppy disks lying
around the office.  This article will focus on the different ways
of gaining access to that information which is most often left
unprotected.

To begin with I will discuss the most vulnerable aspect of any
security plan, people.  Individuals are the weakest link in any
security system whether it be a guard check point or a CN/A
operator, the reason this is so is because when ever a human is
brought into the picture to determine whether or not to give access
or information to another human more often than not a judgement
call has to be made.  As human beings we have feelings like sorrow
and pity to deal with, and those feelings can and are exploited.

Now lets say you wanted to gain access to a certain building that
required some sort of Key-Card to open the door.  With out having
one yourself you could either 1) steal one, 2) make your own, or 3)
walk in behind someone else who does have one.  Number 3 is the one
I want to expand on here.  I have used this method myself, for
legitimate purposes of course.  By looking like you belong in said
building and waiting by the door with a confused and sad look on
your face you could say to someone "I left my Key-Card at home" and
just walk in behind them.  Now this probably wouldn't work at a
small company but more likely at a large institution with several
entrances, use the back door!  When I said look like you belong I
mean dress accordingly.  i.e. to go to a high tech software company
you should be wearing a suit with a briefcase in hand.  Just in
case why don't you case the establishment for a few days before
your attempt and make note of what the majority of employees are
wearing.

Another scenario could be at a industrial firm that you were
interested in.  In this case we will try and play on another human
feeling, greed.  Chances are in this situation the individuals
responsible for any and all computers are, well less than computer
literate.  You could send them a letter in the mail advertising a
free cleaning and inspection of all personal computers on the
premises.  This is an excellent way of gathering information from
heavily industrialized companies.  Usually places where computers
are practically on the factory floor will be more than happy to let
you clean their machines.  While doing so just copy to your hearts
content, or if you are adventurous you could take a portable and
connect it via a serial port or whatever and copy the entire hard
drive.  Just tell them you are running some diagnostics.

The last scenario I will cover is another example of disguising
yourself.  I know this one works and it seems that people are doing
it quite frequently.  Just get a job with a janitorial firm and
sneak away from the actual work to do your bidding.

After gaining access to any company by whatever means you have to
know where to look.  To begin with go to the largest office you can
find, usually in a corner with a good view.  These prime offices
usually belong to those in the upper echelon of the company. Once
in the office you obviously should start with computers since you
can copy electronic information easier than hardcopy.  Next you
should turn to the desk drawer and file cabinets in the office.
Check the rolodex for dialup #'s and passwords.  Basically don't
leave any stone unturned.  Depending on what you are looking for
you might want to start out in the Data Processing department since
their computers are the heart of the whole business.  From there
you can plant trojan horses, copy proprietary software, or steal
specific data.

Some other means of disguise:

PC Repair Shop Technician
Software Demonstrator

All of the above items can be used for completely legal purposes
also.

The above have all been physical means of gathering information,
now lets turn to other ways.


Van Eck

With the proper equipment it is possible to capture every
electronic pulse that is sent out from a keyboard or a monitor
while you are hidden far away from the actual activity.  The U.S.
Government calls this the Tempest project.  If you are ever in a
government office just take a look at their computers.  I know that
the armed services have all of their computers protected by heavy
metal shielding around all computers, even pc's in army recruiting
stations.  Check the loompatics(sp) catalog for a book called Van-
-Eck Phreaking, it explains the whole process and the equipment
needed. This method would generally be used to steal usernames and
passwords.


Network Protocol Analyzers

If you have access to a Local Area Network you might already have
one of these puppies.  A Network protocol analyzer is a device that
lets you examine every packet that is sent out over a network.  I
am talking about Novell, Banyan and 3COM networks if you are
wondering.  By using one of these you can capture every byte that
travels from any given workstation to the file server.   This
equipment is very expensive but could well be worth it depending on
what you are after.  This method could be used to steal everything
from usernames and passwords to actual data.


Keyboard & Monitor Capture program

I have never done this but I think it could be possible to write a
program (a trojan) that would capture everything that is entered
from the keyboard and everything that goes across the monitor and
save it in a hidden file somewhere on a network.


Old Reliable--Social Engineering

Now (with a known bug) we can social engineer electronically via
E-mail.  The Telnet bug which allows you to send a message to
someone without them knowing the source can be very useful.
Unlimited applications.....And there is always the telephone for
the same purpose.  Just make up a story and try it out.  The
obvious "Hello I am the Sysop please change your password to ____"
is not what I am talking about.  You need to be more creative like
posing as a salesman or a surveyor to get information that will
make your "Crack" easier.


I hope this helps you with your quest for knowledge!!!


The Butler...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                              NIA074 / File 07

                    Invisible Killer Chips Now Availible

                           Jean-Bernard Condat
                            General Secretary
                       Chaos Computer Club France
                               B.P. 8005
                       69351 Lyon Cedex 08, France
                           Tel.: [phone]

Intelligence Newsletter (10 rue du Sentier, 75002 Paris, France)
No. 186 (Jan. 29, 1992), page 2, ISSN 0997-7139
By: Jean-Bernard Condat (CCCF, B.P. 8005, 69351 Lyon Cedex 08, France)


  The military use of computer viruses is often overblown, if not just
simple disinformation as in the recent Iraqi case. But researchers at
Boston University have developed and patented (U.S. patent 5 049 775)
an infinitely more offensive and effective anti-computer agent: the
silicon ant. Micro-electronics has perfected technologies for making
toys and machines so small that they are invisible.

  Using piezoelectric ceramics which expand or contract under an
electric current, the researchers constructed a microscopic ship with
three "legs" on each side and a "cutter" in front. By alternating
current in different sides of each "leg", it bends forward or backward.

  Under remote control the killer chips can be "walked" into a computer
and cut up other microscopic chips, turn around and "walk" away, leaving
invisible damage in the computer system. The killer chips could be solar
powered and therefore have an indefinite life-span.


                             PATENT DESCRIPTION


008245420  WPI Acc No: 90-132421/17
XRPX Acc No: N90-102550
   Piezoelectric micro-machine or robot basic operating unit - made by
    covering silicon cantilever beams projecting from frame with
    piezoelectric material when applied voltages cause them to deflect
Patent Assignee: (UYBO-) BOSTON UNIV
Author (inventor): SMITS J G
Number of Patents: 002
Patent Family:
    CC Number    Kind     Date      Week
    WO 9003665     A     900405     9017   (Basic)
    US 5049775     A     910917     9140
Priority Data (CC,No,Date): US 251565 (880930);
Applications (CC,No,Date): WO 89US4129 (890921);
EP and/or WO Language: English
EP and/or WO Cited Patents:
    No.SR.Pub
Designated States (National): JP (Regional): AT; BE; CH; DE; FR; GB; IT; LU
    ; NL; SE
Abstract (Basic): WO 9003665
         An electrical micromachine is made by securing films (20,22) of
    piezoelectric material to the top surfaces (16,18) of crystalline
    silicon beams (12,14) projecting from a crystalline silicon body (10)
    to form a bimorph structure. A potential applied across the ends
    (24,26) of the piezoelectric films causes the beams to deflect. The
    piezoelectric material used is zinc oxide.
          A number of such micromachines can be assembled to form a robot,
    and when a foot (30) is provided the machine can move itself along a
    surface by sequential deflecting and straightening of the beams. The
    foot can be associated with a toothed wheel to produce rotary motion.
    The micromachine may be solar powered, and can be associated with
    sensors or a microprocessor with programmable memory.
          USE - Microsurgical tools, and robots for grasping, carrying or
    cutting tasks. @(33pp Dwg.No.1/10)@
Abstract (US): 9140 US 5049775
         The piezoelectric actuation machine comprises two cantilever beams
    extending from a frame. The beams comprise a piezoelectric material
    such that application of an electric potential across the material of
    each beam rotationally diplaces the first and second beams relative to
    each other.
           An actuating member is secured between displaceable surfaces on
    the beams and extends orthogonally from a plane through the beams such
    that relative displacement of the beams displaces a portion of the
    member in a direction orthogonal to beam displacement. A rigid object
    contacting the displaced portion of the member is translated relative
    to the member and the frame.
           USE - For piezoelectric micromachines e.g. small robot or
    cutting tool. @(17pp)@
File Segment: EPI
Derwent Class: S05; V06; X25; R46;
Int Pat Class: H01L-041/09
Manual Codes (EPI/S-X): S05-B; V06-M06D; X25-A03E

[Editor's Note: I have not investigated to see if this patent really does
 exist due to the timing of the article so close to the release date.  This
 is a rush-in and I am basing all of its credibility to Chaos Computer
 Club France (CCCF) and Jean-Bernard Condat.]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



Downloaded From P-80 International Information Systems 304-744-2253 12yrs+